double arrow

Разработка структуры базы данных


Выяснив основную часть данных, которые заказчик потребляет или поставляет, можно приступать к созданию структуры базы, то есть структуры её основных таблиц.

1. Работа начинается с составления генерального списка полей – он может насчитывать десятки и даже сотни позиций.

2. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.

3. Далее распределяют поля генерального списка по базовым таблицам. На первом этапе распределение производят по функциональному признаку. Цель – обеспечить, чтобы ввод данных в одну таблицу производился, по возможности, в рамках одного подразделения, а ещё лучше – на одном рабочем месте.

Наметив столько таблиц, сколько подразделений охватывает база данных, приступают к дальнейшему делению таблиц. Критерием необходимости деления является факт множественного повтора данных в соседних записях. На рис. 13.7. показана таблица, у которой в поле Адрес наблюдается повтор данных. Это явное свидетельство того, что таблицу надо поделить на две взаимосвязанные таблицы. (РАСТЯНИТЕ ЭТУ ФИГНЮ,Я ПРАВДА НЕ ЗНАЮ,ЗАЧЕМ ОН СКАЗАЛ ЭТО ПЕРЕРИСОВЫВАТЬ..)




4. В каждой из таблиц намечают Ключевое поле. В качестве такового выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким полем может служить индивидуальный шифр студента. Для таблицы, в которой содержаться расписания занятий, такого поля можно и не найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация неповторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия.

Если в таблице вообще нет никаких полей, которые можно было бы использовать как ключевые, всегда можно ввести дополнительное поле типа Счётчик – оно не может содержать повторяющихся данных по определению.

5. С помощью карандаша и бумаги расчерчиваются связи между таблицами. На рисунке 13.8. показан пример взаимосвязи между группой таблиц, составляющих одну базу данных. Такой чертёж называется Схемой данных.

Существует несколько типов возможных связей между таблицами. Наиболее распространёнными являются связи «один ко многим» и «один к одному». Связь между таблицами организуется на основе общего поля, причём в одной из таблиц оно обязательно должно быть ключевым, то есть на стороне «один» должно выступать ключевое поле, содержащее значения. Значения на стороне «многие» могут повторяться.

Рассмотрим таблицу Клиенты (рис. 13.8). Здесь поле Код Клиента является ключевым. Это понятно, поскольку у каждого клиента должен быть свой уникальный код, идентифицирующий его однозначно. Если мы рассмотрим таблицу Заказы, то увидим, что в ней код клиента не может быть уникальным, поскольку каждый клиент мог сделать сколько угодно много заказов. На схеме данных эти поля соединены Линией связи. С одной стороны эта линия маркирована знаком «1», с другой стороны – знаком «бесконечность». Это графический метод изображения связи «один ко многим».



Ключевым полем в таблице заказов является Код заказа – он однозначно идентифицирует, кто, когда, что заказал и на какую сумму. Здесь же можно узнать, какой сотрудник принял заказ к исполнению. Поскольку один сотрудник может принять множество заказов, поле Код Сотрудника в таблице заказов не является ни уникальным, ни ключевым, зато в таблице Сотрудники это поле уникально.

Про подобные таблицы говорят, что они связаны реляционными отношениями. Соответственно, системы управления, способные работать со связанными таблицами, называют Системами управления реляционными базами данных, а схему данных в технической литературе могут называть Схемой реляционных отношений.

Разработка схемы данных заканчивается “бумажный” этап работы над техническим предложением. Эту схему можно согласовать с заказчиком, после чего приступать к непосредственному созданию базы данных.







Сейчас читают про: