Реферат: Основы работы с базами данных Delphi - текст реферата. Скачать бесплатно.
Банк рефератов, курсовых и дипломных работ. Много и бесплатно. # | Правила оформления работ | Добавить в избранное
 
 
   
Меню Меню Меню Меню Меню
   
Napishem.com Napishem.com Napishem.com

Реферат

Основы работы с базами данных Delphi

Банк рефератов / Программирование

Рубрики  Рубрики реферат банка

закрыть
Категория: Реферат
Язык реферата: Русский
Дата добавления:   
 
Скачать
Архив Zip, 60 kb, скачать бесплатно
Заказать
Узнать стоимость написания уникального реферата

Узнайте стоимость написания уникальной работы

Основы работы с базами данных Delphi Содержание Обзор Требовани я к базам данных Основные концепции реляционных баз данных Шаги проектирования базы данных Приведение к первой нормальной форме Приведение ко второй нормальной форме Приведение к третьей нормальной форме Заключение 1. 1. 1. 2. 3. 4. Обзор 5. В этом уроке описыва ются основы работы с базами данных . Напомн им , что под базой данных понимается некото рая унифицированная совокупность данных , совместн о используемая персоналом /населением группы , предприятия , региона , страны , мира ... Задача базы данны х состоит в хранении всех п редставляющих интерес данных в одном или нескольких местах , причем таким способом , кото рый заведомо исключает ненужную избыточность . В хорошо спроектированной базе данных избыто чность данных исключается , и вероятность сохр анения противоречивых данных минимизирует ся . Таким образом , создание баз данных пре следует две основные цели : понизить избыточно сть данных и повысить их надежность . Во вводном урок е (номер 1) мы дали краткое , “на пальцах” , толкование локальных и серверных баз да нных и пояснили суть технологии клиен т-сервер . На данном уроке мы рассмотрим пр оцесс проектирования баз данных , общий для обеих технологий . И лишь детали его реа лизации будут различаться в разных архитектур ах . Сразу оговоримся , что мы будем рассмат ривать т олько реляционные базы данн ых : во-первых , реляционные базы получили наибол ьшее распространение в мире ; во-вторых , они наиболее “продвинуты” в научном плане ; а в-третьих , ядро баз данных Borland Database Engine , на основе которого работ ают все последние про дукты компании Borland, предназначено именно для работы с реляцион ными базами данных. Жизненный цикл любого программного продук та , в том числе и системы управления б азой данных , состоит (по-крупному ) из стадий проектирования , реализации и эксплуатации . Ест ественно , наиболее значительным фа ктором в жизненном цикле приложения , работающ его с базой данных , является стадия проект ирования . От того , насколько тщательно продума на структура базы , насколько четко определены связи между ее элементами , зависит произв о д ительность системы и ее информа ционная насыщенность , а значит - и время ее жизни. 6. Требования к базам данных Итак , хорошо сп роектированная база данных : · · Удовлетворя ет всем требованиям пользователей к содержимо му базы данных . Перед проекти рованием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных . · · Гарантирует непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила , ограничивающие возможность ввода пользоват елем неверных значений . Для верификации данны х перед непосредственной записью их в таб лицу база данных должна осуществлять вызов правил модели данных и тем самым гаран тировать сохранение целостности информации . · · Обеспечива ет естественное , легкое для восприятия структурирование информации. Качес твенное построение базы позволяет делать запр осы к базе более “прозрачными” и легкими для понимания ; следовательно , снижается вероя тность внесения некорректных данных и улучшае тся кач ество сопровождения базы . · · Удовлетворя ет требованиям пользователей к производительност и базы данных. При больших объемах информации вопросы сохранения производ ительности начинают играть главную роль , сраз у “высвечивая” все недочеты этапа проектирова ния . Следующие пункты представляют основные шаги прое ктирования базы данных : 1. 2. Определить информационные потребности базы данных . 3. 4. Проанализировать объекты реального мира , которые необходимо смоделироват ь в базе данных . Сформировать из эти х объектов сущности и характеристики этих сущностей (например , для сущности “ деталь ” характери стиками могут быть “ название ” , “ цвет ” , “ вес ” и т.п .) и сформировать их сп исок . 5. 6. Поставить в соответствие сущностям и характеристикам - таблицы и с толбцы (поля ) в нотации выбранной Вами СУБД (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle и т.д .). 7. 8. Определить атрибуты , кото рые уникальным образом идентифицируют каждый объект . 9. 10. Выработать правила , котор ые будут устанавливать и поддерживать ц елостность данных . 11. 12. Установить связи между объектами (таблицами и столбцами ), провести нормализацию таблиц . 13. 14. Спланировать вопросы над ежности данных и , при необходимости , сохранени я секретности информации . 1. 1. 1. Основные конц епции реляционных баз данных Прежде чем подр обно рассматривать каждый из этих шагов , о становимся на основных концепциях реляционных баз данных . В реляционной теории одним из главных является понятие отношения . Математически отно ше ние определяется следующим образом . Пусть дан ы n множеств D 1 ,D 2 ,...,D n . Тогда R есть отношени е над этими множествами , если R есть множество упорядоченных наборов вида , где d 1 - элемент и з D 1 , d 2 - элемент из D 2 , ..., d n - элемент из D n . Пр и этом наборы вида называ ются кортежами , а множества D 1 ,D 2 ,...,D n - доменами . Каждый кортеж состоит из элементов , выбираемы х из своих доменов . Эти элементы называютс я атрибутами , а и х значения - значениями атрибутов . рис . 0-a предста вляет на м графическое изображение отношен ия с разных точек зрения. Легко заметить , что отношение является отражением некоторой сущности реального мира (в данн ом случае - сущности “деталь” ) и с точки зрения обработки данных представляет со бой таблицу . Поскольку в локальных базах д анных каждая таблица размещается в отдельном файле , то с точки зрения размещения д анных для локальных баз данных отношение можно отождествлять с файлом . Кортеж представляет собой строку в таблице , или , что то же самое , запись . Атрибут же является столбцом таблицы , или - полем в за писи . Домен же представляется неким обобщенны м типом , который может быть источником для типов полей в записи . Таким обр а зом , следующие тройки терминов являются эквивалентными : · · отношение , таблица , ф айл (для локальных баз данных ) · · кортеж , строка , запис ь · · атрибут , столбец , пол е . Реляционная база данных представляет собой сово купность отношений , содержащих всю необходим ую информацию и объединенных различными связя ми. Атрибут (или набор атрибутов ), который может быть использован для однозначной иденти фикации конкретного кортежа (строки , записи ), на зывается первичным ключом . Первичный ключ не должен иметь доп олнительных атрибутов . Это значит , что если из первичного ключа исключить произволь ный атрибут , оставшихся атрибутов будет недос таточно для однозначной идентификации отдельных кортежей . Для ускорения доступа по первич ному ключу во всех системах управления базами данных (СУБД ) имеется механ изм , называемый индексированием . Грубо говоря , индекс представляет собой инвертированный древовидный список , указы вающий на истинное местоположение записи для каждого первичного ключа . Естественно , в разных СУБД индексы ре ализованы по-разном у (в локальных СУБД - как правило , в вид е отдельных файлов ), однако , принципы их ор ганизации одинаковы. Возможно индексирование отношения с испол ьзованием атрибутов , отличных от первичного к люча . Данный тип индекса называется вторичным и ндексом и применяется в целях уменьшения времени доступа при нахождении данных в отношении , а также для сортировки . Таким образом , если само отношение не упорядочено каким-ли бо образом и в нем могут присутствовать строки , оставшиеся после удаления некоторы х кортежей , то индекс (для локальных СУБД - индексный файл ), напротив , отсортирован. Для поддержания ссылочной целостности дан ных во многих СУБД имеется механизм так называемых внешних ключей . Смысл этого механизма состоит в том , что некоему атрибуту (или группе атрибутов ) одного отношения назначается ссыл ка на первичный ключ другого отношения ; те м самым закрепляются связи подчиненности межд у этими отношениями . При этом отношение , н а первичный ключ которого ссылается внешний ключ другого отношения , называе т с я master-отношением , ил и главным отношением ; а отношение , от которого исходит ссылка , называется detail-отношением , или подчиненным отношением . После назначения такой ссылки СУБД имеет возможност ь автоматически отслеживать вопросы “ненарушения “ связей меж ду отношениями , а именно : · · если Вы попытаетесь вставить в подчиненную таблицу запись , дл я внешнего ключа которой не существует со ответствия в главной таблице (например , там нет еще записи с таким первичным ключо м ), СУБД сгенерирует ошибку ; · · ес ли Вы попы таетесь удалить из главной таблицы запись , на первичный ключ которой имеется хотя бы одна ссылка из подчиненной таблицы , СУБД также сгенерирует ошибку . · · если Вы попытаетесь изменить первичный ключ записи главной т аблицы , на которую имеется хотя бы о дна ссылка из подчиненной таблицы , СУБД та кже сгенерирует ошибку . Замечание. Существует два подхода к удалению и изменению записей из главной таблицы : 1. 1. 2. Запретить удаление всех записей , а также изменение первичных ключ ей главной табли цы , на которые имеются ссылки подчиненной таблицы . 3. 4. Распространить всякие из менения в первичном ключе главной таблицы на подчиненную таблицу , а именно : · o o если в главной та блице удалена запись , то в подчиненной таб лице должны быть удалены все записи , ссылающиеся на удаляемую ; o o если в главной та блице изменен первичный ключ записи , то в подчиненной таблице должны быть изменены все внешние ключи записей , ссылающихся на изменяемую . Итак , после тог о как мы ознакомились с основными поняти ями реляционной теории , можно перейти к детальному рассмотрению шагов проектирования базы данных , которые мы перечислили на стр . * . 1. 1. 1. Шаги проектир ования базы данных I. Первый шаг состоит в определении информаци онных потребностей базы данных . Он включает в себя опро с будущих пользователей для того , чтобы понять и задокументировать их требования . Следует выяснить следующие в опросы : · · сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системо й ; · · какие данные использ уются разными приложениями ; смогут ли Ваши приложения совместно использовать какие-либо из этих данных ; · кто будет вводить данные в базу и в какой форме ; ка к часто будут изменяться данные ; · достаточно ли будет для Вашей предметной области одной базы или Вам потребуется несколько баз данных с различными структурами ; · какая информация является наиболее чувствительной к скорости е е извлечения и изменения . II. Следующий шаг включает в себя анализ о бъекто в реального мира , которые необходим о смоделировать в базе данных. Формирование концептуальной модели базы д анных включает в себя : · · идентификацию функционал ьной деятельности Вашей предметной области . Н апример , если речь идет о деятельности пре дприятия , то в качестве функциональной д еятельности можно идентифицировать ведение учета работающих , отгрузку продукции , оформление за казов и т.п . · · идентификацию объектов , которые осуществляют эту функциональную дея тельность , и формирование из их операций п оследовательности событий , которые помогут Вам идентифицировать все сущности и взаимо связи между ними . Например , процесс “ведение учета работающих” идентифицирует такие сущност и как РАБОТНИК , ПРОФЕССИЯ , ОТДЕЛ . · · идентификацию характерис тик этих сущно стей . Например , сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника , Фамилия , Имя , Отче ство , Профессия , Зарплата . · · идентификацию взаимосвяз ей между сущностями . Например , каким образом сущности РАБОТНИК , ПРОФЕССИЯ , ОТДЕЛ взаимо действуют друг с другом ? Работник имеет од ну профессию (для простоты !) и значится в одном отделе , в то время как в одно м отделе может находиться много работников . III. Третий шаг заключается в установлении соот ветствия между сущностями и характерис тик ами предметной области и отношениями и ат рибутами в нотации выбранной СУБД . Поскольку каждая сущность реального мира обладает некими характеристиками , в совокупности образующи ми полную картину ее проявления , можно пос тавить им в соответствие набор отно ш ений (таблиц ) и их атрибутов (полей ). Перечислив все отношения и их атрибут ы , уже на этом этапе можно начать устр анять излишние позиции . Каждый атрибут должен появляться только один раз ; и Вы долж ны решить , какое отношение будет являться владельцем какого набора атрибутов. IV. На четвертом шаге определяются атрибуты , которые уникальным образом идентифицируют каждый объект . Это необходимо для того , чтобы система могла получить любую единичную строку таблицы . Вы должны определить первичный ключ для каж дого из отношений . Если нет возможности идентифицировать кортеж с помощью одного атрибута , то первичный ключ нужно сделать составным - из нескольких атрибутов . Хорошим примером может быть первичный ключ в табл ице работников , состоящий из фамилии , имени и отчеств а . Первичный ключ гарант ирует , что в таблице не будет содержаться двух одинаковых строк . Во многих СУБД имеется возможность помимо первичного определя ть еще ряд уникальных ключей . Отличие уникального ключа от первичного состоит в том , что уникальный ключ не является главным идентифицирующи м фактором записи и на него не может ссылаться внешний ключ другой таблицы . Ег о главная задача - гарантировать уникальность значения поля. V. Пятый шаг пр едполагает выработку правил , которые будут ус танавливать и поддержива ть целостность да нных . Будучи определенными , такие правила в клиент-серверных СУБД поддерживаются автоматически - сервером баз данных ; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение. Эти правила включают : · · опре деление типа данных · · выбор набора символо в , соответствующего данной стране · · создание полей , опира ющихся на домены · установка значений по умолчанию · определение ограничен ий целостности опред еление проверочных условий . VI. На шестом шаге устанавливаются связи между объектами (таблицами и столбцами ) и производится очень важная операция для исключ ения избыточности данных - нормализация таблиц. Каждый из различных типов связей долж ен быть смоделирован в базе данных . Сущест вует несколько типов связей : · · связь “один-к-одному” · · связь “один-ко-многим” · · связь “многие-ко-многим” . Связь “один-к-одному ” представляет собой простейший вид связи данных , когда первичный ключ таблицы являет ся в то же время внешним ключом , ссыла ющи мся на первичный ключ другой табли цы . Такую связь бывает удобно устанавливать тогда , когда невыгодно держать разные по размеру (или по другим критериям ) данные в одной таблице . Например , можно выделить данные с подробным описанием изделия в отдельную табл и цу с установлением связи “один-к-одному” для того чтобы не занимать оперативную память , если эти данные используются сравнительно редко. Связь “один-ко-многим” в большинстве случа ев отражает реальную взаимосвязь сущностей в предметной области . Она реализуе тся у же описанной парой “внешний ключ-первичный кл юч” , т.е . когда определен внешний ключ , ссыл ающийся на первичный ключ другой таблицы . Именно эта связь описывает широко распростран енный механизм классификаторов . Имеется справочна я таблица , содержащая наз в ания , им ена и т.п . и некие коды , причем , первичн ым ключом является код . В таблице , собираю щей информацию - назовем ее информационной таб лицей - определяется внешний ключ , ссылающийся на первичный ключ классификатора . После этого в нее заносится не названи е из классификатора , а код . Такая система становится устойчивой от изменения названия в классификаторах . Имеются способы быстрой “по дмены” в отображаемой таблице кодов на их названия как на уровне сервера БД (дл я клиент-серверных СУБД ), так и на уровне пол ь зовательского приложения . Но об этом - в дальнейших уроках. Связь “многие-ко-многим” в явном виде в реляционных базах данных не поддерживается . Однако имеется ряд способов косвенной ре ализации такой связи , которые с успехом во змещают ее отсутствие . Один из наиболее распространенных способов заключается во вве дении дополнительной таблицы , строки которой состоят из внешних ключей , ссылающихся на первичные ключи двух таблиц . Например , имеются две таблицы : КЛИЕНТ и ГРУППА _ИНТЕРЕСОВ . Один человек может быть вкл ю че н в различные группы , в то время как группа может объединять различных людей . Дл я реализации такой связи “многие-ко-многим” вв одится дополнительная таблица , назовем ее КЛИ ЕНТЫ _В _ГРУППЕ , строка которой будет иметь два внешних ключа : один будет ссылаться н а первичный ключ в таблице КЛИЕНТ , а другой - на первичный ключ в таблице ГРУППА _ИНТЕРЕСОВ . Таким образом в таблицу КЛИЕНТЫ _В _ГРУППЕ можно записывать любое количество людей и любое количеств о групп. Итак , после определения таблиц , полей , индексов и связей между таблицами следу ет посмотреть на проектируемую базу данных в целом и проанализировать ее , используя правила нормализации , с целью устранения ло гических ошибок . Важность нормализации состоит в том , что она позволяет разбить больши е отношения , как прав и ло , содержащ ие большую избыточность информации , на более мелкие логические единицы , группирующие толь ко данные , объединенные “по природе” . Таким образом , идея нормализации заключается в сл едующем . Каждая таблица в реляционной базе данных удовлетворяет усл о вию , в соответствии с которым в позиции на пе ресечении каждой строки и столбца таблицы всегда находится единственное значение , и н икогда не может быть множества таких знач ений. После применения правил нормализации логи ческие группы данных располагаются не б олее чем в одной таблице . Это дает сле дующие преимущества : · · данные легко обновля ть или удалять · · исключается возможность рассогласования копий данных · · уменьшается возможность введения некорректных данных . Процесс нормализац ии заключает ся в приведении таблиц в так называемые нормальные фор мы . Существует несколько видов н ормальных форм : первая нормальная форма (1НФ ), вторая нормальная форма (2НФ ), третья нормаль ная форма (3НФ ), нормальная форма Бойса-Кодда (НФБК ), четвертая нормальная фор ма (4НФ ), пятая нормальная форма (5НФ ). С практической точки зрения , достаточно трех первых форм - следует учитывать время , необходимое системе для “соединения” таблиц при отображении их на экране . Поэтому мы ограничимся изуче нием процесса приведения отно ш ений к первым трем формам . Этот процесс включает : · · устранение повторяющихся групп (приведение к 1НФ ) · · удаление частично за висимых атрибутов (приведение к 2НФ ) · · удаление транзитивно зависимых атрибутов (приведение к 3НФ ). Рассмотрим ка ждый из этих процессов подробней. Приведение к первой нормальной форме 1. Когда поле в данной записи содержит более одного зна чения для каждого вхождения первичного ключа , такие группы данных называются повторяющимися группами . 1НФ не допускает наличия та ких мног означных полей . Рассмотрим пример базы данных предприятия , содержащей таблицу ОТДЕЛ со следующими значениями (атрибут , выделенный курсиво м , является первичным ключом ): Табл . A: ОТДЕЛ Номер _отдела Название Руководитель Бюджет Расп оложение 100 про даж 000 1000000 Моск ва 100 продаж 000 1000000 Зеленоград 600 разработок 120 1100000 Тверь 100 продаж 000 1000000 Калуга Для привед ения этой таблицы к 1НФ мы должны устр анить атрибут (поле ) Расположение из таблицы ОТДЕЛ и создать новую таблицу РАСПОЛОЖЕ НИЕ _ОТДЕЛОВ , в которой определить перв ичный ключ , являющийся комбинацией номера отд ела и его расположения (Номер _отдела +Распо ложение - см . табл . b). Теперь для каждого расп оложения отдела существуют различные строки ; тем самым мы устранили повторяющиеся г р уппы. Табл . B: РАСПОЛОЖЕНИЕ _ОТДЕЛОВ Номер _отдела Расположение 100 Москва 100 Зеленоград 600 Тверь 100 Калуга 2. Приведение к о второй нормальной форме 3. Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов , котор ые зави сят только от части первичного ключа . Таки е атрибуты называются частично зависимыми . Неключевые атрибуты заключают в себе информацию о данной сущности предметной области , но не идентифи цируют ее уникальным образом . Например , предпо ложим , что мы хоти м распределить работ ников по проектам , ведущимся на предприятии . Для этого создадим таблицу ПРОЕКТ с со ставным первичным ключом , включающим номер ра ботника и идентификатор проекта (Номер _работн ика +ИД _проекта , в табл . c выделены курсивом ). Табл . C: ПРОЕКТ Номер _ работн ика ИД _проекта Фамилия Назв _проекта Описание _ проекта Продукт 28 БРЖ Иванов Биржа программа 17 ДОК Петров Документы программа 06 УПР Сидоров Управление адм.меры В этой таблице возникает следующая проблема . Атрибуты На зв _проекта , Описание _проекта и Продукт относятся к проекту как сущности и , с ледовательно , зависят от атрибута ИД _проекта (являющегося частью первичного ключа ), но не от атрибута Номер _работника . Следовательно , они являются частично зависимыми от сост авног о первичного ключа . То же с амое можно сказать и об атрибуте Фамилия , который зависит от атрибута Номер _работн ика , но не зависит от атрибута ИД _прое кта . Для нормализации этой таблицы (приведения ее в 2НФ ) удалим из нее атрибуты Н омер _работника и Фамилия и с о здадим другую таблицу (назовем ее РАБОТНИК _В _ПРОЕКТЕ ), которая будет содержать только эти два атрибута , и они же будут составлять ее первичный ключ. 4. Приведение к третьей нормальной форме Третий этап про цесса приведения таблиц к нормальной форме состоит в удалении всех неключевых ат рибутов , которые зависят от других неключевых атрибутов . Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибу тами ), являющимся первичным ключом . Предположим , например , что мы добавили поля Номер _ру ководи т еля и Телефон в таблицу ПРОЕКТ , находящуюся в 2НФ (первичным ключом является поле ИД _проекта ). Атрибут Телефо н логически связан с атрибутом Номер _руко водителя , неключевым полем , но не с атрибу том ИД _проекта , являющимся первичным ключом (табл . d). Табл . D: ПРОЕКТ ИД _проекта Номер _ руководителя Телефон Назв _ проекта Описан ие _ проекта Продукт БРЖ 02 2-21 Биржа программа ДОК 12 2-43 Документы програм ма УПР 08 2-56 Управление адм.ме ры Для нормализации этой таблицы (приведения ее в 3 НФ ) удалим атрибут Телефон , изменим Номер _руковод ителя на Руководитель и сделаем атрибут Р уководитель внешним ключом , ссылающимся на ат рибут Номер _работника (первичный ключ ) в т аблице РАБОТНИКИ . После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следу ю щим образом : Табл . E: ПРОЕКТ ИД _проекта Руководитель Назв _ проекта Описание _ проекта Продукт БРЖ 02 Биржа программа ДОК 12 Документы программа УПР 08 Управление адм.меры Табл . F: РАБ ОТНИКИ Номер _ рабо тника Фамилия Имя Отчество Но ме р _ отдела Код _ профес Телефон Зарплата 04 Иванов Иван Иванович 100 инж 2-69 500 08 Петров Петр Петрович 200 мндж 2-56 1000 23 Сидоров Иван Петрович 200 мндж 2-45 800 Теперь , когда мы научились про водить нормализацию таблиц с целью устранения избыточног о дублирования данных и гр уппирования информации в логически связанных единицах , необходимо сделать ряд замечаний по вопросам проектирования баз данных . Необходи мо четко понимать , что разбиение информации на более мелкие единицы с одной сторон ы , способств у ет повышению надежности и непротиворечивости базы данных , а с другой стороны , снижает ее производительность , так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя ) на обратное “соединение” таблиц при представле н ии информации на экране . Иногда для достижения требуемой п роизводительности нужно сделать отход от кано нической нормализации , при этом ясно осознава я , что необходимо обеспечить меры по предо твращению противоречивости в данных . Поэтому всякое решение о нео б ходимости то го или иного действия по нормализации мож но принимать только тщательно проанализировав предметную область и класс поставленной за дачи . Может потребоваться несколько итераций для достижения состояния , которое будет желае мым компромиссом между ч е ткостью представления и реальными возможностями техники . Здесь уже начинается искусство... VII. Седьмой шаг является последним в нашем списке , но не последним по важности в процессе проекти рования базы данных . На этом шаге мы д олжны спланировать вопросы на дежности дан ных и , при необходимости , сохранения секретнос ти информации . Для этого необходимо ответить на следующие вопросы : · кто будет иметь права (и каки е ) на использование базы данных · кто будет иметь права на модификацию , вставку и удаление данн ых · нужно ли делать различие в правах доступа · каким образом обе спечить общий режим защиты информации и т. п . 1. Заключение На данном уроке мы познакомились с основами теории реляц ионных баз данных , изучили требования к ба зам данных , а также основ ные шаги по проектированию баз данных . Кроме того , рассмотрели очень важный для проектирования б аз данных вопрос нормализации таблиц и пр облемы , связанные с этим процессом . Теперь мы можем осознанно приступать к созданию приложений , работающих с базами да н ных.
1Архитектура и строительство
2Астрономия, авиация, космонавтика
 
3Безопасность жизнедеятельности
4Биология
 
5Военная кафедра, гражданская оборона
 
6География, экономическая география
7Геология и геодезия
8Государственное регулирование и налоги
 
9Естествознание
 
10Журналистика
 
11Законодательство и право
12Адвокатура
13Административное право
14Арбитражное процессуальное право
15Банковское право
16Государство и право
17Гражданское право и процесс
18Жилищное право
19Законодательство зарубежных стран
20Земельное право
21Конституционное право
22Конституционное право зарубежных стран
23Международное право
24Муниципальное право
25Налоговое право
26Римское право
27Семейное право
28Таможенное право
29Трудовое право
30Уголовное право и процесс
31Финансовое право
32Хозяйственное право
33Экологическое право
34Юриспруденция
 
35Иностранные языки
36Информатика, информационные технологии
37Базы данных
38Компьютерные сети
39Программирование
40Искусство и культура
41Краеведение
42Культурология
43Музыка
44История
45Биографии
46Историческая личность
47Литература
 
48Маркетинг и реклама
49Математика
50Медицина и здоровье
51Менеджмент
52Антикризисное управление
53Делопроизводство и документооборот
54Логистика
 
55Педагогика
56Политология
57Правоохранительные органы
58Криминалистика и криминология
59Прочее
60Психология
61Юридическая психология
 
62Радиоэлектроника
63Религия
 
64Сельское хозяйство и землепользование
65Социология
66Страхование
 
67Технологии
68Материаловедение
69Машиностроение
70Металлургия
71Транспорт
72Туризм
 
73Физика
74Физкультура и спорт
75Философия
 
76Химия
 
77Экология, охрана природы
78Экономика и финансы
79Анализ хозяйственной деятельности
80Банковское дело и кредитование
81Биржевое дело
82Бухгалтерский учет и аудит
83История экономических учений
84Международные отношения
85Предпринимательство, бизнес, микроэкономика
86Финансы
87Ценные бумаги и фондовый рынок
88Экономика предприятия
89Экономико-математическое моделирование
90Экономическая теория

 Анекдоты - это почти как рефераты, только короткие и смешные Следующий
Кальмар, в случае крайней опасности, рефлекторно выпускает из себя чернильное пятно.
Есть этот рефлекс и у человека. А вот чернил нет.
Anekdot.ru

Узнайте стоимость курсовой, диплома, реферата на заказ.

Обратите внимание, реферат по программированию "Основы работы с базами данных Delphi", также как и все другие рефераты, курсовые, дипломные и другие работы вы можете скачать бесплатно.

Смотрите также:


Банк рефератов - РефератБанк.ру
© РефератБанк, 2002 - 2016
Рейтинг@Mail.ru