Hi! My name is Damir. I’m co-founder at IFAB.ru and i’m pretty good at these scary things

  • Startups
  • E-Commerce
  • Process development
  • Process implementation
  • Project management
  • Financial modeling
  • Business strategy

You can reach me out via these networks

Are you hiring? Check out my CV

My CV page

Информатика лекции 3

Глава 1. История развития баз данных
1.1. Развитие вычислительной техники

В настоящее время можно выделить два основных направления использования вычислительной техники. Первое направление – применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Развитие этой области способствовало интенсификации методов численного решения сложных математических задач, появлению языков программирования, ориентированных на удобную запись численных алгоритмов. Характерной особенностью данного направления является наличие сложных алгоритмов обработки, которые применяются к простым по структуре данным, объем которых сравнительно невелик.

Второе направление , которое непосредственно относится к теме нашего повествования, – это использование средств ЭВМ в автоматизированных информационных системах. Информационная система представляет собой программно-аппаратный комплекс, обеспечивающий выполнение следующих функций:

• надежное хранение данных в памяти компьютера;

• выполнение специфических для данного приложения преобразований данных и вычислений;

• предоставление пользователям удобного и интуитивно понятного интерфейса.

Обычно такие системы имеют дело с большими объемами данных, имеющими достаточно сложную структуру. Классическими примерами информационных систем могут служить банковские системы, автоматизированные системы управления предприятиями, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д.

Второе направление возникло несколько позже первой. Это было связано с тем, что на заре вычислительной техники возможности компьютеров по хранению данных были очень ограниченными. Ведь долговременное и надежное хранение данных возможно только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания. Оперативная память компьютеров, как известно этим свойством обычно не обладает, В первых компьютерах использовались два вида устройств внешней памяти – магнитные ленты и барабаны. Емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным. Магнитные же барабаны (они ближе всего к современным магнитным дискам с фиксированными головками) давали возможность произвольного доступа к данным, но имели ограниченный объем хранимой информации.

Эти ограничения не являлись существенными для численных расчетов. Даже если программа должна была обработать (или произвести) большой объем информации, при программировании, то можно было продумать расположение этой информации во внешней памяти (например, на последовательной магнитной ленте), обеспечивающее эффективное выполнение этой программы. Однако в информационных системах совокупность взаимосвязанных информационных объектов фактически отражает модель объектов реального мира. А потребность пользователей в информации, адекватно отражающей состояние реальных объектов, требует сравнительно быстрой реакции системы на их запросы. В этом случае наличие сравнительно медленных устройств хранения данных, к которым относятся магнитные ленты и барабаны, было недостаточным.

В результате эволюции вычислительной техники, именно требования нечисловых приложений вызвали появление съемных магнитных дисков с подвижными головками, что явилось революцией в истории ЭВМ. Эти устройства внешней памяти обладали существенно большей емкостью, чем магнитные барабаны, обеспечивали удовлетворительную скорость доступа к данным в режиме произвольной выборки, а возможность смены диска на устройстве позволяла иметь практически неограниченный архив данных.

С появлением магнитных дисков началась история систем управления данными во внешней памяти. До этого каждая прикладная программа, которой требовалось хранить данные во внешней памяти, сама определяла расположение каждой порции данных на магнитной ленте или барабане и выполняла обмены между оперативной памятью и устройствами внешней памяти с помощью программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих программ операционной системы). Такой режим работы не позволял или очень затруднял поддержание на одном внешнем носителе нескольких архивов долговременно хранимой информации. Кроме того, каждой прикладной программе приходилось решать проблемы именования частей данных и структуризации данных во внешней памяти.

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

Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных зависят от конкретной системы управления файлами и их типа. В свою очередь система управления файлами (файловая система) берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса во внешней памяти и обеспечение доступа к данным.

В разных файловых системах операции создания, считывания и записи в файл могут несколько отличаться. Главное, что следует отметить, это то, что структура записи файла известна только программе, которая с ним работает, система управления файлами ее не знает. Поэтому для того, чтобы извлечь некоторую информацию из файла, необходимо точно знать структуру записи файла с точностью до бита. Каждая программа, работающая с файлом, должна иметь у себя внутри структуру данных, соответствующую структуре этого файла. Поэтому при изменении структуры файла требуется изменять структуру программы, а это требует новой компиляции, то есть процесса перевода программы в исполняемые машинные коды. Такая ситуации характеризуется как зависимость программ от данных. Для информационных систем характерным является наличие большого числа различных пользователей (программ), каждый из которых имеет свои специфические алгоритмы обработки информации, хранящейся в одних и тех же файлах. Изменение структуры файла, необходимое для одной программы, требует исправления и перекомпиляции и дополнительной отладки всех остальных программ, работающих с этим файлом. Все выше сказанное было первым существенным недостатком файловых систем, которое привело к созданию новых систем хранения и управления информацией.

Поскольку файловые системы являются общим хранилищем файлов, принадлежащих, разным пользователям, системы управления файлами должны обеспечивать авторизацию доступа к файлам. В общем виде подход состоит в том, что по отношению к каждому зарегистрированному пользователю данной вычислительной системы для каждого существующего файла указываются действия, которые разрешены или запрещены данному пользователю. В большинстве современных систем управления файлами применяется подход к защите файлов, впервые реализованный в ОС UNIX. В этой ОС каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к которой относится пользователь, и его собственный идентификатор в группе. При каждом файле хранится полный идентификатор пользователя, который создал этот файл, и фиксируется, какие действия с файлом может производить его создатель, какие действия с файлом доступны для других пользователей той же группы и что могут делать с файлом пользователи других групп. Администрирование режимом доступа к файлу в основном выполняется его создателем-владельцем. Для множества файлов, отражающих информационную модель одной предметной области, такой децентрализованный принцип управления доступом вызывал дополнительные трудности, И отсутствие централизованных методов управления доступом к информации послужило причиной разработки СУБД.

Еще одной причиной стала необходимость обеспечения эффективной параллельной работы многих пользователей с одними и теми же файлами. В общем случае системы управления файлами обеспечивали режим многопользовательского доступа. Если операционная система поддерживает многопользовательский режим, вполне реальна ситуация, когда два или более пользователя одновременно пытаются работать с одним и тем же файлом. Если все пользователи собираются только читать файл, ничего страшного не произойдет, но если хотя бы один из них будет изменять файл, для корректной работы этих пользователей требуется взаимная синхронизация их действий по отношению к файлу.

В системах управления файлами обычно применялся следующий подход. В операции открытия файла (первой и обязательной операции, с которой должен начинаться сеанс работы с файлом) среди прочих параметров указывался режим работы (чтение или изменение). Если к моменту выполнения этой операции некоторым пользовательским процессом PROC – 1 файл был уже открыт другим процессом PROC – 2 в режиме изменения, то в зависимости от особенностей системы процессу PROC – 1 либо сообщалось о невозможности открытия файла, либо он блокировался до тех пор, пока в процессе PROC – 2 не выполнялась операция закрытия файла.

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

Эти недостатки послужили тем толчком, который заставил разработчиков информационных систем предложить новый подход к управлению информацией. Этот подход был реализован в рамках новых программных систем, названных впоследствии Системами Управления Базами Данных (СУБД), а сами хранилища информации, которые работали под управлением данных систем, назывались базами или банками данных (БД и БнД).

История развития СУБД насчитывает 40 лет. В 1968 году была введена в эксплуатацию первая промышленная Система Управления Базами Данных IMS фирмы IBM. В 1975 году появился первый стандарт ассоциации по языкам систем обработки данных – Conference of Data System Languages ( CODASYL ) , который определил ряд фундаментальных понятий в теории систем баз данных, которые до сих пор являются основополагающими для сетевой модели данных.

В дальнейшее развитие теории баз данных большой вклад был сделан американским математиком Э.Ф. Коддом, который является создателем реляционной модели данных. В 1981 году Э.Ф. Кодд получил за создание реляционной модели и реляционной алгебры престижную премию Тьюринга Американской Ассоциации по Вычислительной Технике.

Менее двух десятков лет прошло с этого момента, но стремительное развитие вычислительной техники, изменение ее принципиальной роли в жизни общества, обрушившийся бум персональных ЭВМ и, наконец, появление мощных рабочих станций и сетей ЭВМ повлияло также и на развитие технологии баз данных. Можно выделить четыре этапа в развитии данного направления в обработке данных. Однако необходимо заметить, что все же нет жестких временных ограничений в этих этапах: они плавно переходят один в другой и даже сосуществуют параллельно, но тем не менее выделение этих этапов позволяет более четко охарактеризовать отдельные стадии развития технологии баз данных, подчеркнуть особенности, специфичные для каждого этапа.
Вернуться
1.2. Первый этап развития СУБД

Первый этап развития СУБД связан с организацией баз данных на больших машинах типа IBM 360/370, ЕС-ЭВМ и мини-ЭВМ типа PDP11 (фирмы Digital Equipment Corporation – DEC ), разных моделях HP (фирмы Hewlett Packard ),

Базы данных хранились во внешней памяти центральной ЭВМ, пользователями этих баз данных были задачи, запускаемые в пакетном режиме. Интерактивный режим доступа обеспечивался с помощью консольных терминалов, которые не обладали собственными вычислительными ресурсами (процессором, внешней памятью) и служили только устройствами ввода-вывода для центральной ЭВМ. Программы доступа к БД писались на различных языках и запускались как обычные числовые программы. Мощные операционные системы обеспечивали возможность условно параллельного выполнения всего множества задач. Эти системы можно было отнести к системам распределенного доступа, потому что база данных была централизованной, хранилась на устройствах внешней памяти центральной ЭВМ, а доступ к ней поддерживался от многих пользователей задач.

Особенности этого этапа развития выражаются в следующем:

• все СУБД базируются на мощных мультипрограммных операционных системах (MVS SVM, RTE, OSRV, RSX, UNIX), в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа.

• функции управления распределением ресурсов в основном осуществляются операционной системой (ОС);

• поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным;

• значительная роль отводится администрированию данных;

• проводятся серьезные работы по обоснованию и формализации реляционной модели данных, в результате чего была создана первая система (System R), реализующая идеологию реляционной модели данных;

• проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции.

• результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД;

• появляются первые языки высокого уровня для работы с реляционной моделью данных. Однако отсутствуют стандарты для этих первых языков.
Вернуться
1.3. Второй этап развития СУБД

Второй этап развития СУБД.

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

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

Постоянное снижение цен на персональные компьютеры сделало их доступными не только для организаций и фирм, но и для отдельных пользователей. Компьютеры стали инструментом для ведения документации и собственных учетных функций. Это все сыграло как положительную, так и отрицательную роль в области развития баз данных. Кажущаяся простота и доступность персональных компьютеров и их программного обеспечения породила множество дилетантов. Эти разработчики, считая себя знатоками, стали проектировать недолговечные базы данных, которые не учитывали многих особенностей объектов реального мира. Много было создано систем-однодневок, которые не отвечали законам развития и взаимосвязи реальных объектов. Однако доступность персональных компьютеров заставила пользователей из многих областей знаний, которые ранее не применяли вычислительную технику в своей деятельности, обратиться к ним. И спрос на развитые удобные программы обработки данных заставлял поставщиков программного обеспечения поставлять все новые и новые системы, которые принято называть настольными ( desktop ) СУБД.

Значительная конкуренция среди поставщиков заставляла совершенствовать эти системы, предлагая новые возможности, улучшая интерфейс и быстродействие систем, снижая их стоимость. Наличие на рынке большого числа СУБД, выполняющих сходные функции, потребовало разработки методов экспорта-импорта данных для этих систем и открытия форматов храпения данных. Но и в этот период появлялись любители, которые вопреки здравому смыслу разрабатывали собственные СУБД, используя стандартные языки программирования. Это был тупиковый вариант, потому что дальнейшее развитие показало, что перенести данные из нестандартных форматов в новые СУБД было гораздо труднее, а в некоторых случаях требовало таких трудозатрат, что легче было бы все разработать заново, по данные все равно надо было переносить на новую более перспективную СУБД. И это тоже было результатом недооценки тех функций, которые должна была выполнять СУБД,

Особенности этого этапа следующие:

• Все СУБД были рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Компьютер персональный, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главный бухгалтер определял проводки, соответствующие первичным документам.

• Большинство СУБД имели развитый и удобный пользовательский интерфейс.

• Появился интерактивный режим работы с БД как в рамках описания БД, так и в рамках проектирования запросов.

• Большинство СУБД предлагали развитый и удобный инструментарий для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток ( Labels ), графических конструкторов запросов, которые достаточно просто могли быть собраны в единый комплекс.

• Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний, табличный вид структур данных.

• При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц.

• В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД.

• Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим – к отсутствию инструментальных средств администрирования БД.

• И, наконец, последняя и в настоящий момент весьма положительная особенность – это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД.

• Вполне работоспособные приложения, разработанные, например, на Clipper , работали на PC 286,

В принципе, их даже трудно назвать полноценными СУБД, Яркие представители этого семейства — очень широко использовавшиеся до недавнего времени СУБД Dbase ( Dbase III , Dbase IV ), FoxPro , Clipper , Paradox .
Вернуться
1.4. Третий этап развития СУБД

Третий этап развития СУБД или распределенные базы данных.

Известно, что история развивается по спирали, поэтому после процесса «персонализации» с середины 80-х г.г. начался обратный процесс – интеграции. Увеличилось количество локальных сетей, все больше информации стало передаваться между компьютерами, в результате остро встала задача согласованности данных, хранящихся и обрабатывающихся в разных местах, но логически связанных друг с другом. Возникли задачи, связанные с параллельной обработкой транзакций (последовательностью операций над БД), переводом из одного непротиворечивого состояния в другое. Успешное решение этих задач привело к появлению распределенных данных, сохраняющих все преимущества настольных СУБД и в то же время позволяющих организовать параллельную обработку информации и поддержку целостности БД.

Особенности этого этапа следующие :

• Практически все СУБД обеспечивают поддержку полной реляционной модели, а именно:

• структурной целостности – допустимыми являются только данные, представленные в виде отношений реляционной модели;

• языковой целостности , то есть языков манипулирования данными высокого уровня (в основном SQL);

• ссылочной целостности , контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий не возможности со стороны СУБД нарушить эти ограничения.

• Большинство СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД на разных платформах, практически неразличим;

• Необходимость поддержки многопользовательской работы с базой данных и возможность децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных;

• Потребность в новых реализациях вызвала создание серьезных теоретических трудов по оптимизации реализаций распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД.

• Для того чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически вес современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных СУБД второго этапа;

• Разработка ряда стандартов в рамках языков описания и манипулирования данными начиная с SQL89, SQL92, SQL99 и технологий по обмену данными между различными СУБД, к которым можно отнести и протокол ODBC ( Open DataBase Connectivity ), предложенный фирмой Microsoft .

• Начало работ, связанных с концепцией объектно-ориентированных БД. Представителями СУБД, относящимся к этапу, можно считать MS Access начиная с версии 97 и все современные серверы баз данных Огас1е 7, Огас1е 8.4, MS SQL 6.5, MS SQL 7.0, System 10, System 11, Informix, DB2, SQL Base и другие современные серверы баз данных, которых в настоящий момент насчитывается несколько десятков.
Вернуться
1.5. Перспективы развития СУБД

Перспективы развития СУБД.

Новый этап развития СУБД, развивающийся в настоящее время характеризуется появлением технологии доступа к данным через Интернет. Отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный браузер Интернет, например Microsoft Internet Explorer или Opera , в результате для конечного пользователя процесс обращения к данным происходит аналогично скольжению по Всемирной Паутине. При этом встроенный в загружаемые пользователем HTML-страницы код, написанный обычно на языке PHP , Java-Script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. Удобство данного подхода привело к тому, что он стал использоваться не только для удаленного доступа к базам данных, но и для пользователей локальной сети предприятий.

Простые задачи обработки данных, не связанные со сложными алгоритмами, требующими согласованного изменения данных во многих взаимосвязанных объектах, достаточно просто и эффективно могут быть построены по данной архитектуре. В этом случае для подключения нового пользователя к возможности использовать данную задачу не требуется установка дополнительного клиентского программного обеспечения. Однако алгоритмически сложные задачи рекомендуется реализовывать в архитектуре «клиент-сервер» с разработкой специального клиентского программного обеспечения.

Глава 2. Основные понятия и модели БД
2.1. Основные понятия баз данных

Не смотря на то, что большинство современных авторов употребляют термины «банк данных» и «база данных» как синонимы, в общеотраслевых руководящих материалах по созданию банков данных Государственного комитета по науке и технике (ГКНТ), изданных в 1982 г ., эти понятия различаются. Там приводятся следующие определения банка данных, базы данных и СУБД:

Банк данных (БнД) – это система специальным образом организованных данных – баз данных, программных, технических, языковых, организационно-методических средств, предназначенных для обеспечения централизованного накопления и коллективного многоцелевого использования данных.

База данных (БД) – именованная совокупность данных, отражающая состояние объектов и их отношений в рассматриваемой предметной области.

Система управления базами данных (СУБД) – совокупность языковых и программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями.

Программы, с помощью которых пользователи работают с базой данных, называются приложениями . В общем случае с одной базой данных могут работать множество различных приложений. Например, если база данных моделирует некоторое предприятие, то для работы с ней может быть создано приложение, которое обслуживает подсистему учета кадров, другое приложение может быть посвящено работе подсистемы расчета заработной платы сотрудников, третье приложение работает как подсистемы складского учета, четвертое приложение посвящено планированию производственного процесса. При рассмотрении приложении, работающих с одной базой данных, предполагается, что они могут работать параллельно и независимо друг от друга, и именно СУБД призвана обеспечить работу множества приложений с единой базой данных таким образом, чтобы каждое из них выполнялось корректно, но при этом учитывало все изменения в базе данных, вносимые другими приложениями.

Терминология в СУБД, да и сами термины «база данных» и «банк данных» заимствованы из финансовой деятельности. Это не случайно и объясняется тем, что работа с информацией и работа с денежными массами во многом схожи, поскольку и там и там отсутствует персонификация объекта обработки; две банкноты достоинством в сто рублей столь же неотличимы и взаимозаменяемы, как два одинаковых байта (естественно, за исключением серийных номеров). Вы можете положить деньги на некоторый счет и предоставить возможность вашим родственникам или коллегам использовать их для иных целей. Вы можете поручить банку оплачивать ваши расходы с вашего счета или получить их наличными в другом банке, и это будут уже другие денежные купюры, но их ценность будет эквивалентна той, которую вы имели, когда клали, их на ваш счет.

Вернуться
2.2. Система организации баз данных

В процессе научных исследований, посвященных тому, как именно должна быть устроена СУБД, предлагались различные способы реализации. Самым жизнеспособным из них оказалась предложенная американским комитетом по стандартизации ANSI (American National Standards Institute) трехуровневая система организации БД, изображенная на рис.1.

Рис.1 Трехуровневая модель СУБД, предложенная ANSI.

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

Концептуальный уровень – центральное управляющее звено, здесь база данных представлена в наиболее общем виде, который объединяет данные, используемые всеми приложениями, работающими с данной базой данных. Фактически концептуальный уровень отражает обобщенную модель предметной области (объектов реального мира), для которой создавалась база данных. Как любая модель, концептуальная модель отражает только существенные, с точки зрения обработай, особенности объектов реального мира.

Физический уровень – собственно данные, расположенные в файлах или в страничных структурах, расположенных на внешних носителях информации.

Эта архитектура позволяет обеспечить логическую (между уровнями 1 и 2) и физическую (между уровнями 2 и 3) независимость при работе с данными. Логическая независимость предполагает возможность изменения одного приложения без корректировки других приложений, работающих с этой же базой данных. Физическая независимость, предполагает .возможность переноса хранимой информации с одних носителей на другие при сохранении работоспособности всех приложений, работающих с данной базой данных. Это именно то, чего не хватало при использовании файловых систем.

Выделение концептуального уровня позволило разработать аппарат централизованного управления базой данных.

Более полно модель базы данных представляет следующая схема рис.2.

Рис. 2

Инфологическая модель данных – описание, выполненное с использованием естественного языка, математических формул, таблиц, графиков и других средств, понятных всем людям, работающих над проектированием базы данных. Это человеко-ориентированная модель полностью независима от физических параметров среды хранения данных. Этой средой может быть память человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта модель продолжала отражать предметную область.

Даталогическая модель данных – компьютерно-ориентированная модель в которой модели описаны на языке конкретной СУБД. С ее помощью СУБД дает возможность программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на внешних запоминающих устройствах по физической модели данных.

Трехуровневая архитектура (инфологический, даталогический и физический уровни) позволяет обеспечить независимость хранимых данных от использующих их программ.

Вернуться
2.3. Пользователи базы данных

Администратор базы данных может при необходимости переписать хранимые данные на другие носители информации или реорганизовать их физическую структуру, изменив лишь физическую модель данных. Администратор базы данных может подключить к системе любое число новых пользователей (новых приложений), дополнив, если надо, даталогическую модель. Указанные изменения физической и даталогической моделей не будут замечены существующими пользователями системы (окажутся “прозрачными” для них), так же как не будут замечены и новые пользователи. Следовательно, независимость данных обеспечивает возможность развития системы баз данных без разрушения существующих приложений.

Как любой программно-организационно-техннческий комплекс, банк данных существует во времени и в пространстве. Он имеет определенные стадии своего развития:

• Проектирование;

• Реализация;

• Эксплуатация;

• Модернизация и развитие;

• Полная реорганизация.

На каждом этапе своего существования с банком данных связаны разные категории пользователей.

Определим основные категории пользователей и их роль в функционировании банка данных:

Конечные пользователи – это основная категория пользователей, в интересах которых и создается банк данных. В зависимости от особенностей создаваемого банка данных круг его конечных пользователей может существенно различаться. Это могут быть случайные пользователи , обращающиеся к БД время от времени за получением некоторой информации, а могут быть регулярные пользователи. В качестве случайных пользователей могут рассматриваться, например, возможные клиенты вашей фирмы, просматривающие каталог вашей продукции или услуг с обобщенным или подробным описанием того и другого. Регулярными пользователями могут быть ваши сотрудники, работающие со специально разработанными для них программами, которые обеспечивают автоматизацию их деятельности при выполнении своих должностных обязанностей. Например, менеджер, планирующий работу сервисного отдела компьютерной фирмы, имеет в своем распоряжении программу, которая помогает ему планировать и распределять текущие заказы, контролировать ход их выполнения, заказывать на складе необходимые комплектующие для новых заказов. Главный принцип состоит в том, что от конечных пользователей не должно требоваться каких-либо специальных знаний в области вычислительной техники и языковых средств,

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

Разработчики и администраторы приложений – это группа пользователей, которая функционирует во время проектирования, создания и реорганизации банка данных. Администраторы приложений координируют работу разработчиков при разработке конкретного приложения или группы приложений, объединенных в функциональную подсистему. Разработчики конкретных приложений работают с той частью информации из базы данных, которая требуется для конкретного приложения.

Вернуться
2.4. Иерархическая модель баз данных

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

Иерархическая модель данных была исторически первой структурой БД, видимо, из-за того, что древовидные иерархические структуры широко используются в повседневной человеческой деятельности. Это всевозможные классификаторы, ускоряющие поиск требуемой информации, иерархические функциональные структуры управления. Наиболее известной иерархической СУБД до сих пор остается IMS

Элементами иерархической модели являются поле и сегмент . Структурные связи определяются подчиненностью, в силу чего сегмент более низкого уровня называют порожденным, а более высокого уровня – исходным. Сегмент самого верхнего уровня носит название «корневой». Именно через него осуществляется доступ к иерархической БД (точка входа). Экземпляр порожденного сегмента не может существовать в отсутствие экземпляра исходного сегмента. В силу этого положения при удалении экземпляра исходного сегмента удаляются и все экземпляры порожденных сегментов.

Если структура запроса совпадает со структурой иерархической БД, то такая модель данных обладает самым высоким быстродействием и потому чаще всего применяется в суперЭВМ. В противном случае быстродействие может резко снизиться или данные совсем могут быть не получены. Чтобы избежать последнего неприятного случая, в иерархическую модель данных вводят еще один тип связи – логический.

Сегмент – это согласно терминологии Американской Ассоциации по базам данных DBTG ( Data Base Task Group ) запись, при этом в рамках иерархической модели определяются два понятия: тип сегмента или т ип записи и экземпляр сегмента или экземпляр записи .

Тип сегмента – это поименованная совокупность типов элементов данных, в него входящих. Экземпляр сегмента образуется из конкретных значений полей или элементов данных , в него входящих. Каждый тип сегмента в рамках иерархической модели образует некоторый набор однородных записей. Для возможности различия отдельных записей в данном наборе каждый тип сегмента должен иметь ключ или набор ключевых атрибутов (полей, элементов данных). Ключом называется набор элементов данных, однозначно идентифицирующих экземпляр сегмента. Например, рассматривая тип сегмента, описывающий сотрудника организации, мы должны выделить те характеристики сотрудника, которые могут его однозначно идентифицировать в рамках базы данных предприятия. Если предположить, что на предприятии могут работать однофамильцы, то, вероятно, наиболее надежным будет идентифицировать сотрудника по его табельному номеру. Однако если мы будем строить БД, содержащую описание множества граждан, например нашей страны, то, скорее всего, нам придется в качестве ключа выбрать совокупность полей, отражающих его паспортные данные.

В иерархической модели сегменты объединяются в ориентированный древовидный граф. При этом полагают, что направленные ребра графа отражают иерархические связи между сегментами: каждому экземпляру сегмента, стоящему выше по иерархии и соединенному с данным типом сегмента, соответствует несколько (множество) экземпляров данного (подчиненного) типа сегмента. Тип сегмента, находящийся на более высоком уровне иерархии, называется логически исходным по отношению к типам сегментов, соединенным с данным направленными иерархическими ребрами, которые в свою очередь называются логически подчиненными по отношению к этому типу сегмента. Иногда исходные сегменты называют сегментами-предками, а подчиненные сегменты называют сегментами-потомками.

Рис.3. Пример иерархической связи между сегментами

Схема иерархической базы данных представляет собой совокупность отдельных деревьев, каждое дерево в рамках модели называется физической базой данных. Каждая физическая база данных удовлетворяет следующим иерархическим ограничениям:

• в каждой физической БД существует один корневой сегмент, то есть сегмент, у которого нет логически исходного (родительского) типа сегмента;

• каждый логически исходный сегмент может быть связан с произвольным числом логически подчиненных сегментов;

• каждый логически подчиненный сегмент может быть связан только с одним логически исходным (родительским) сегментом.

Очень важно понимать различие между сегментом и типом сегмента – оно такое же, как между типом переменной и самой переменной: сегмент является экземпляром типа сегмента. Например, у нас может быть тип сегмента Группа (Номер, Староста) и сегменты этого типа, такие как (4305, Петров Ф. И.) пли (383, Кустова Т. С.).

Между экземплярами сегментов также существуют иерархические связи. Рассмотрим, например, иерархический граф, представленный на рис. 4

Рис.4 Пример структуры иерархического дерева

Каждый тип сегмента может иметь множество соответствующих ему экземпляров. Между экземплярами сегментов также существуют иерархические связи.

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

Пример иерархической базы данных.

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

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

Если заказывается типичная модель , то выясняется, какая модель и есть ли она в наличии, если модель есть, то надо уменьшить количество компьютеров данной модели в данном филиале на покупаемое количество. На этом будем считать заказ выполненным, однако при оформлении заказа может потребоваться задание полной спецификации покупаемого изделия.

Если заказывается индивидуальная модель, то требуется описать весь состав новой модели.

Для того чтобы можно было бы принимать заказы на индивидуальные модели, нам понадобится информация о наличие конкретных деталей на складе, в этом случае нам необходимо второе дерево – Склады.
Вернуться
2.5. Сетевая модель баз данных

На разработку стандарта сетевой модели большое влияние оказал американский ученый Ч. Бахман. Основные принципы сетевой модели данных были разработаны в середине 60-х годов. Эталонный вариант сетевой модели данных описан в отчетах рабочей группы по языкам баз данных (COnference on DAta SYstem Languages) CODASYL ( 1971 г .), который определил базовые понятия, модели и формальный язык описания.

Базовыми объектами сетевой модели являются:

• элемент данных;

• агрегат данных;

• запись;

• набор данных.

Элемент данных – это минимальная информационная единица, доступная пользователю с использованием СУБД.

Агрегат данных соответствует следующему уровню обобщения в модели. В модели определены агрегаты двух типов: агрегат типа вектор и агрегат типа повторяющаяся группа.

Агрегат данных имеет имя, и в системе допустимо обращение к агрегату по имени. Агрегат типа вектор соответствует линейному набору элементов данных. Например, агрегат Адрес может быть представлен следующим образом:
Агрегат типа повторяющаяся группа соответствует совокупности векторов данных. Например, агрегат Зарплата соответствует типу повторяющаяся группа с числом повторений 12.
Записью – это совокупность агрегатов или элементов данных, моделирующая некоторый класс объектов реального мира. Понятие записи соответствует понятию «сегмент» в иерархической модели. Для записи, так же как и для сегмента, вводятся понятия типа записи и экземпляра записи.

Следующим базовым понятием в сетевой модели является понятие « Набор ».

Набором – это двухуровневый граф, связывающий отношением «один-ко-многим» два типа записи.

Набор фактически отражает иерархическую связь между двумя типами записей. Родительский тип записи в данном наборе называется владельцем набора, а дочерний тип записи – членом того же набора.

Для любых двух типов записей может быть задано любое количество наборов, которые их связывают. Фактически наличие подобных возможностей позволяет промоделировать отношение «многие-ко-многим» между двумя объектами реального мира, что выгодно отличает сетевую модель от иерархической. В рамках набора возможен последовательный просмотр экземпляров членов набора, связанных с одним экземпляром владельца набора.

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

Вернуться
2.6. Реляционная модель баз данных

Реляционная модель была предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г . В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой . В своей статье Е.Ф.Кодда утверждал, что “реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления”. Другими словами, представление данных, согласно его теории не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название “реляционная” происходит от английского relation – “отношение”).

Базовыми объектами реляционной модели являются:

• Наименьшая единица данных

• Домен

• Заголовок

Наименьшая единица данных – это отдельное атомарное (неразложимое) для данной модели значение данных. Так, в одной предметной области фамилия, имя и отчество могут рассматриваться как единое значение, а в другой как три различных значения.

Доменом называется множество атомарных значений одного и того же типа. Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута (например, для организации транзитного рейса можно дать запрос “Выдать рейсы, в которых время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву”). Если же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено смысла: стоит ли сравнивать номер рейса со стоимостью билета?

Отношение на доменах D1, D2, …, Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, …, An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,…,n).
Тело состоит из меняющегося во времени множества кортежей , где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (Ai:Vi), (i=1,2,…,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным , степени два бинарным , степени три тернарным , …, а степени n – n-арным.

Кардинальное число или мощность отношения – это число его кортежей. Мощность отношения “Рейс” равна 10. Кардинальное число отношения изменяется во времени в отличие от его степени.

Поскольку отношение – это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами A1, A2, …, An. Говорят, что множество атрибутов K=(Ai, Aj, …, Ak) отношения R является возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от времени условия:

Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, …, Ak.

Минимальность: ни один из атрибутов Ai, Aj, …, Ak не может быть исключен из K без нарушения уникальности.

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

Вышеупомянутые и некоторые другие математические понятия явились теоретической базой для создания реляционных СУБД, разработки соответствующих языковых средств и программных систем, обеспечивающих их высокую производительность, и создания основ теории проектирования баз данных. Однако для массового пользователя реляционных СУБД можно с успехом использовать неформальные эквиваленты этих понятий:

Отношение – Таблица (иногда Файл), Кортеж – Строка (иногда Запись), Атрибут – Столбец, Поле.

При этом принимается, что “запись” означает “экземпляр записи”, а “поле” означает “имя и тип поля”.

Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать такую базу данных как совокупность таблиц.

Структура реляционной базы данных должна отвечать следующим требованиям:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.

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

4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются однородные значения данных (даты, фамилии, целые числа или денежные суммы).

5. Полное информационное содержание базы данных представляется в виде явных значений данных и такой метод представления является единственным. В частности, не существует каких-либо специальных “связей” или указателей, соединяющих одну таблицу с другой.

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

Вернуться
2.7. Сравнительная характеристика моделей БД

Вид модели

Достоинства

Недостатки

Иерархическая

– простота понимания

– простота оценки операционных характеристик

– отношения М:М могут быть реализованы только искусственно
– могут быть избыточные данные
– усложняются операции включения и удаления
– удаление исходных объектов ведет к удалению порожденных объектов
– процедурный характер манипулирования данными
– доступ к любому порожденному узлу возможен только через корневой узел
– сильная зависимость логической и физической БД
– сильно ограниченный набор структур запроса

Сетевая

– сохранение информации при уничтожении владельца
– более богатая, чем в иерархической МД, структура запросов
– меньшая, чем у иерархических МД, зависимость логической и физической БД

– сложность структуры: прикладной программист должен детально знать логическую структуру БД (для навигации в наборах и записях)
– возможна потеря независимости данных при реорганизации БД
– представление в прикладной программе сложнее, чем в иерархической МД

Реляционная

– простота работы и отражение представлений поль-зователя
– гибкость (соединение, разделение файлов)
– простота внедрения плоских файлов
– отделение от физической реализации (независимость)
– произвольная структура запросов
– хорошее теоретическое обоснование

– низкая производительность
– необходимость глубокого рассмотрения отношений (нормализация), в том числе отношений М:М
– возможность логических ошибок и необходимость осторожной работы с моделью
– линейность структуры таблицГлава 3. Проектирование реляционной БД
3.1. Инфологическая модель данных.

Цель инфологического моделирования – обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).

Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности.

Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.

Вернуться
3.2. Характеристика связей

При построении инфологических моделей можно использовать язык ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). В них сущности изображаются помеченными прямоугольниками, ассоциации – помеченными ромбами или шестиугольниками, атрибуты – помеченными овалами, а связи между ними – ненаправленными ребрами, над которыми может проставляться степень связи (1 или буква, заменяющая слово “много”) и необходимое пояснение.

Между двумя сущностям, например, А и В возможны четыре вида связей.

Первый тип – связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В:
Студент может не “получить” стипендию, получить обычную или одну из повышенных стипендий.

Второй тип – связь ОДИН-КО-МНОГИМ (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В.
Квартира может пустовать, в ней может жить один или несколько жильцов.

Так как между двумя сущностями возможны связи в обоих направлениях, то существует еще два типа связи МНОГИЕ-К-ОДНОМУ (М:1) и МНОГИЕ-КО-МНОГИМ (М:N).

Пример 1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется БРАК, то существует четыре возможных представления такой связи:
Характер связей между сущностями не ограничивается перечисленными. Существуют и более сложные связи: множество связей между одними и теми же сущностями
(пациент, имея одного лечащего врача, может иметь также несколько врачей-консультантов; врач может быть лечащим врачом нескольких пациентов и может одновременно консультировать несколько других пациентов); тренарные связи
(врач может назначить несколько пациентов на несколько анализов, анализ может быть назначен несколькими врачами нескольким пациентам и пациент может быть назначен на несколько анализов несколькими врачами); связи более высоких порядков, семантика (смысл) которых иногда очень сложна.

В приведенных примерах для повышения иллюстративности рассматриваемых связей не показаны атрибуты сущностей и ассоциаций во всех ER-диаграммах. Так, ввод лишь нескольких основных атрибутов в описание брачных связей значительно усложнит ER-диаграмму. В связи с этим язык ER-диаграмм используется для построения небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:

СУЩНОСТЬ (атрибут 1, атрибут 2 , …, атрибут n)

АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2, …]

(атрибут 1, атрибут 2, …, атрибут n)

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

Так, рассмотренный выше пример множества связей между сущностями, может быть описан на ЯИМ следующим образом:

Врач (Номер_врача, Фамилия, Имя, Отчество, Специальность)

Пациент (Регистрационный_номер, Номер койки, Фамилия,

Имя, Отчество, Адрес, Дата рождения, Пол)

Лечащий_врач [Врач 1, Пациент M]

(Номер_врача, Регистрационный_номер)

Консультант [Врач M,Пациент N]

(Номер_врача, Регистрационный_номер).
Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией. Проиллюстрируем такое утверждение на примерах, связанных с описанием брачных связей.

Пример 2. Отдел записей актов гражданского состояния (ЗАГС) имеет дело не со всеми людьми, а только с теми, кто обратился с просьбой о регистрации брака, рождения или смерти. Поэтому в странах, где допускаются лишь традиционные браки, отделы ЗАГС могут размещать сведения о регистрируемых браках в единственной сущности:

Брак (Номер_свидетельства, Фамилия_мужа, Имя_мужа,

Отчество_мужа, Дата_рождения_мужа, Фамилия_жены,

… , Дата_регистрации, Место_регистрации, …),

Пример 3. Теперь рассмотрим ситуацию, когда отдел ЗАГС расположен в стране, допускающей многоженство. Если для регистрации браков использовать сущность “Брак” примера 2, то будут дублироваться сведения о мужьях, имеющих несколько жен (см. табл.1).

Таблица 1

Номер свидетельства

Фамилия мужа

Фамилия жены

Дата регистрации

1-ЮБ 154745

Петухов

Курочкина

06/03/1991

1-ЮБ 163489

Петухов

Пеструшкина

11/08/1991

1-ЮБ 169887

Петухов

Рябова

12/12/1992

1-ЮБ 169878

Селезнев

Уточкина

12/12/1992

1-ЮБ 154746

Парасюк

Свинюшкина

06/03/1991

1-ЮБ 169879

Парасюк

Хаврония

12/12/1992

Дублирование можно исключить созданием дополнительной сущности “Мужья”

Мужья (Код_М, Фамилия, Имя, Отчество, Дата рождения, Место рождения)

и заменой сущности “Брак” характеристикой со ссылкой на соответствующее описание в сущности “Мужья”.

Брак (Номер свидетельства, Код_М, Фамилия жены, …,

Дата регистрации, …){Мужья}.

Таблица 2

Код_М

Фамилия

Имя

Отчество

Год/р.

Место рожд.

111

Петухов

Альфред

Остапович

1971

г. Цапелька

112

Селезнев

Вавила

Абрамович

1973

г. Гусев

113

Парасюк

Гораций

Федулович

1972

г. Свиньин

Таблица 3

Номер свидетельства

Код_М

Фамилия жены

Имя жены

Дата регистрации

1-ЮБ 154745

111

Курочкина

Августина

06/03/1991

1-ЮБ 163489

111

Пеструшкина

Мариана

11/08/1991

1-ЮБ 169877

111

Рябова

Милана

12/12/1992

1-ЮБ 169878

112

Уточкина

Вероника

12/12/1992

1-ЮБ 154746

113

Свинюшкина

Эльвира

06/03/1991

1_ЮБ 169879

113

Хаврония

Руфина

12/12/1992

Пример 4. Наконец, рассмотрим случай, когда какой-либо организации потребовались данные о наличии в ней семейных пар, а для хранения сведений о сотрудниках уже имеется сущность

Сотрудники (Табельный_номер, Фамилия, Имя, …).

Использование, рассмотренной в примере 2, сущности “Брак” нецелесообразно: в “Сотрудники” уже есть фамилии, имена, отчества супругов. Поэтому создадим ассоциацию

Брак [Сотрудник 1, Сотрудник 1]

(Табельный_номер_мужа, Табельный_номер_жены, …),

связывающую между собой определенные экземпляры сущности “Сотрудники”.

Отметим, что ER-диаграмма описывает структуру размещения данных о браках в отделах ЗАГС стран, допускающих групповые браки, а ER-диаграммы примера 1, описания любых видов браков в организациях, где есть сущности “мужчины” и “женщины”, включающие холостых и незамужних.

В ER-диаграммах связь это линия, соединяющая геометрические фигуры, изображающие сущности, атрибуты, ассоциации и другие информационные объекты. В тексте же этот термин используется для указания на взаимозависимость сущностей. Если эта взаимозависимость имеет атрибуты, то она называется ассоциацией.

Вернуться
3.3. Классификация сущностей

Настал момент разобраться в терминологии. К.Дейт определяет три основные класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс ассоциативных сущностей – обозначения.

Стержневая сущность (стержень) – это независимая сущность (несколько подробнее она будет определена ниже).

В рассмотренных ранее примерах стержни – это “Студент”, “Квартира”, “Мужчины”, “Врач”, “Брак” (из примера 2) и другие, названия которых помещены в прямоугольники.

Ассоциативная сущность (ассоциация) – это связь вида “многие-ко-многим” (“-ко-многим” и т.д.) между двумя или более сущностями или экземплярами сущности (как в примере 4). Ассоциации рассматриваются как полноправные сущности: они могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые сущности;

могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов, необходимых для указания связей, но и любое число других атрибутов, характеризующих связь. Например, ассоциации “Брак” из примеров 1 и 4 содержат ключевые атрибуты “Код_М”, “Код_Ж” и “Табельный номер мужа”, “Табельный номер жены”, а также уточняющие атрибуты “Номер свидетельства”, “Дата регистрации”, “Место_регистрации”, “Номер записи в книгу ЗАГС” и т.д.

Характеристическая сущность (характеристика) – это связь вида “многие-к-одной” или “одна-к-одной” между двумя сущностями (частный случай ассоциации). Единственная цель характеристики в рамках рассматриваемой предметной области состоит в описании или уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько жен (пример 3), книга – несколько характеристик переиздания (исправленное, дополненное, переработанное, …) и т.д.

Существование характеристики полностью зависит от характеризуемой сущности: женщины лишаются статуса жен, если умирает их муж.

Для описания характеристики используется новое предложение ЯИМ, имеющее в общем случае вид:

ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, …)

{СПИСОК ХАРАКТЕРИЗУЕМЫХ СУЩНОСТЕЙ}.

Расширим также язык ER-диаграмм, введя для изображения характеристики трапецию.

Элементы расширенного языка ER-диаграмм

Обозначающая сущность или обозначение – это связь вида “многие-к-одной” или “одна-к-одной” между двумя сущностями и отличается от характеристики тем, что не зависит от обозначаемой сущности.

Пример 5. Рассмотрим пример, связанный с зачислением сотрудников в различные отделы организации.

При отсутствии жестких правил (сотрудник может одновременно зачисляться в несколько отделов или не зачисляться ни в один отдел) необходимо создать описание с ассоциацией Зачисление:

Отделы (Номер отдела, Название отдела, …)

Служащие (Табельный номер, Фамилия, …)

Зачисление [Отделы M, Служащие N]

(Номер отдела, Табельный номер, Дата зачисления).

Однако, при условии, что каждый из сотрудников должен быть обязательно зачислен в один из отделов, можно создать описание с обозначением Служащие:

Отделы (Номер отдела, Название отдела, …)

Служащие (Табельный номер, Фамилия, … , Номер отдела,

Дата зачисления)[Отделы]

В данном примере служащие имеют независимое существование (если удаляется отдел, то из этого не следует, что также должны быть удалены служащие такого отдела). Поэтому они не могут быть характеристиками отделов и названы обозначениями.

Обозначения используют для хранения повторяющихся значений больших текстовых атрибутов: “кодификаторы” изучаемых студентами дисциплин, наименований организаций и их отделов, перечней товаров и т.п.

Описание обозначения внешне отличается от описания характеристики только тем, что обозначаемые сущности заключается не в фигурные скобки, а в квадратные:

ОБОЗНАЧЕНИЕ (атрибут 1, атрибут 2, …)[СПИСОК

ОБОЗНАЧАЕМЫХ СУЩНОСТЕЙ].

Как правило, обозначения не рассматриваются как полноправные сущности, хотя это не привело бы к какой-либо ошибке.

Обозначения и характеристики не являются полностью независимыми сущностями, поскольку они предполагают наличие некоторой другой сущности, которая будет “обозначаться” или “характеризоваться”. Однако они все же представляют собой частные случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях, обозначениях и иметь свои собственные (более низкого уровня) характеристики. Подчеркнем также, что все экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром характеризуемой сущности. Однако допускается, чтобы некоторые экземпляры характеризуемой сущности не имели связей. Правда, если это касается браков, то сущность “Мужья” должна быть заменена на сущность “Мужчины” (нет мужа без жены).

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

В заключение рассмотрим пример построения инфологической модели базы данных “Питание”, где должна храниться информация о блюдах (рис. 2.3), их ежедневном потреблении, продуктах, из которых приготавливаются эти блюда, и поставщиках этих продуктов. Информация будет использоваться поваром и руководителем небольшого предприятия общественного питания, а также его посетителями.

1. Лобио по грузински
Ломаную очищенную фасоль, нашинкованный лук посолить, посыпать перцем и припустить в масле с небольшим количеством бульона; добавить кинзу, зелень петрушки, рейган (базилик) и довести до готовности. Затем запечь в духовке.
Фасоль стручковая (свежая или консервированная) 200,
Лук зеленый 40, Масло сливочное 30, Зелень 10.
Выход 210. Калорий 725.

Пример кулинарного рецепта

С помощью указанных пользователей выделены следующие объекты и характеристики проектируемой базы:

Блюда, для описания которых нужны данные, входящие в их кулинарные рецепты: номер блюда (например, из книги кулинарных рецептов), название блюда, вид блюда (закуска, суп, горячее и т.п.), рецепт (технология приготовления блюда), выход (вес порции), название, калорийность и вес каждого продукта, входящего в блюдо.

Для каждого поставщика продуктов: наименование, адрес, название поставляемого продукта, дата поставки и цена на момент поставки.

Ежедневное потребление блюд (расход): блюдо, количество порций, дата.

Анализ объектов позволяет выделить:
стержни Блюда, Продукты и Города;
ассоциации Состав (связывает Блюда с Продуктами) и
Поставки (связывает Поставщиков с Продуктами);
обозначение Поставщики;
характеристики Рецепты и Расход.

ER-диаграмма модели показана далее. а модель на языке ЯИМ имеет следующий вид:

Блюда (БЛ, Блюдо, Вид)

Продукты (ПР, Продукт, Калорийность)

Поставщики (ПОС, Город, Поставщик) [Город]

Состав [Блюда M, Продукты N] (БЛ, ПР, Вес (г))

Поставки [Поставщики M, Продукты N] (ПОС, ПР, Дата_П, Цена, Вес (кг))

Города (Город, Страна)

Рецепты (БЛ, Рецепт) {Блюда}

Расход (БЛ, Дата_Р, Порций) {Блюда}

В этих моделях Блюдо, Продукт и Поставщик – наименования, а БЛ, ПР и ПОС – цифровые коды блюд, продуктов и организаций, поставляющих эти продукты.

Инфологическая модель базы данных “Питание”

Вернуться
3.4. О первичных и внешних ключах

Напомним, что ключ или возможный ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Каждая сущность обладает хотя бы одним возможным ключом. Один из них принимается за первичный ключ. При выборе первичного ключа следует отдавать предпочтение несоставным ключам или ключам, составленным из минимального числа атрибутов. Нецелесообразно также использовать ключи с длинными текстовыми значениями (предпочтительнее использовать целочисленные атрибуты). Так, для идентификации студента можно использовать либо уникальный номер зачетной книжки, либо набор из фамилии, имени, отчества, номера группы и может быть дополнительных атрибутов, так как не исключено появление в группе двух студентов (а чаще студенток) с одинаковыми фамилиями, именами и отчествами. Плохо также использовать в качестве ключа не номер блюда, а его название, например, ” Закуска из плавленых сырков “Дружба” с ветчиной и соленым огурцом” или “Заяц в сметане с картофельными крокетами и салатом из красной капусты”.

Не допускается, чтобы первичный ключ стержневой сущности (любой атрибут, участвующий в первичном ключе) принимал неопределенное значение. Иначе возникнет противоречивая ситуация: появится не обладающий индивидуальностью, и, следовательно не существующий экземпляр стержневой сущности. По тем же причинам необходимо обеспечить уникальность первичного ключа.

Теперь о внешних ключах:

Если сущность С связывает сущности А и В, то она должна включать внешние ключи, соответствующие первичным ключам сущностей А и В.

Если сущность В обозначает сущность А, то она должна включать внешний ключ, соответствующий первичному ключу сущности А.

В п. рассматривался пример, где “Служащие” обозначали “Отделы” и включали внешний ключ “Номер отдела”, соответствующий первичному ключу сущности “Отделы”.

Связь между первичными и внешними ключами сущностей иллюстрируется рис.

Структуры: а – ассоциации; б – обозначения (характеристики)

Здесь для обозначения любой из ассоциируемых сущностей (стержней, характеристик, обозначений или даже ассоциаций) используется новый обобщающий термин “Цель” или “Целевая сущность”.

Таким образом, при рассмотрении проблемы выбора способа представления ассоциаций и обозначений в базе данных основной вопрос, на который следует получить ответ: “Каковы внешние ключи?”. И далее, для каждого внешнего ключа необходимо решить три вопроса:

1. Может ли данный внешний ключ принимать неопределенные значения (NULL-значения)? Иначе говоря, может ли существовать некоторый экземпляр сущности данного типа, для которого неизвестна целевая сущность, указываемая внешним ключом? В случае поставок это, вероятно, невозможно – поставка, осуществляемая неизвестным поставщиком, или поставка неизвестного продукта не имеют смысла. Но в случае с сотрудниками такая ситуация однако могла бы иметь смысл – вполне возможно, что какой-либо сотрудник в данный момент не зачислен вообще ни в какой отдел. Заметим, что ответ на данный вопрос не зависит от прихоти проектировщика базы данных, а определяется фактическим образом действий, принятым в той части реального мира, которая должна быть представлена в рассматриваемой базе данных. Подобные замечания имеют отношение и к вопросам, обсуждаемым ниже.

2. Что должно случиться при попытке УДАЛЕНИЯ целевой сущности, на которую ссылается внешний ключ? Например, при удалении поставщика, который осуществил по крайней мере одну поставку. Существует три возможности:

КАСКАДИРУЕТСЯ

Операция удаления “каскадируется” с тем, чтобы удалить также поставки этого поставщика.

ОГРАНИЧИВАЕТСЯ

Удаляются лишь те поставщики, которые еще не осуществляли поставок. Иначе операция удаления отвергается.

УСТАНАВЛИВАЕТСЯ

Для всех поставок удаляемого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем этот поставщик удаляется. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

3. Что должно происходить при попытке ОБНОВЛЕНИЯ первичного ключа целевой сущности, на которую ссылается некоторый внешний ключ? Например, может быть предпринята попытка обновить номер такого поставщика, для которого имеется по крайней мере одна соответствующая поставка. Этот случай для определенности снова рассмотрим подробнее. Имеются те же три возможности, как и при удалении:

КАСКАДИРУЕТСЯ

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

ОГРАНИЧИВАЕТСЯ

Обновляются первичные ключи лишь тех поставщиков, которые еще не осуществляли поставок. Иначе операция обновления отвергается.

УСТАНАВЛИВАЕТСЯ

Для всех поставок такого поставщика NULL-значение внешний ключ устанавливается в неопределенное значение, а затем обновляется первичный ключ поставщика. Такая возможность, конечно, неприменима, если данный внешний ключ не должен содержать NULL-значений.

Таким образом, для каждого внешнего ключа в проекте проектировщик базы данных должен специфицировать не только поле или комбинацию полей, составляющих этот внешний ключ, и целевую таблицу, которая идентифицируется этим ключом, но также и ответы на указанные выше вопроса (три ограничения, которые относятся к этому внешнему ключу).

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

NULL-значения не допустимы

УДАЛЕНИЕ ИЗ (цель) КАСКАДИРУЕТСЯ

ОБНОВЛЕНИЕ (первичный ключ цели) КАСКАДИРУЕТСЯ

Указанные спецификации представляют зависимость по существованию характеристических сущностей.

Вернуться
3.5. Ограничения целостности

Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).

Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).

Выделяют три группы правил целостности:
Целостность по сущностям.
Целостность по ссылкам.
Целостность, определяемая пользователем.

Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение.

Значение внешнего ключа должно либо:
быть равным значению первичного ключа цели;
быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.

Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов, диапазон значений (экзаменационная оценка от 2 до 5), принадлежность набору значений (пол “М” или “Ж”).

Вернуться
3.6. О построении инфологической модели

Студент, познакомившийся лишь с материалом данной и предшествующей глав, не сможет правильно воспринять и оценить тех советов и рекомендаций по построению хорошей инфологической модели, которые десятилетиями формировались крупнейшими специалистами в области обработки данных. Для этого необходимо, чтобы студент предварительно реализовал хотя бы один проект информационной системы, предложил его реальным пользователям и побыл администратором базы данных и приложений столь долго, чтобы осознать хотя бы небольшую толику проблем, возникающих из-за недостаточно продуманного проекта. Опыт показывает, что любые теоретические рекомендации воспринимаются всерьез лишь после нескольких безрезультатных попыток оживления неудачно спроектированных систем. (Хотя есть и такие проектировщики, которые продолжают верить, что смогут реанимировать умирающий проект с помощью изменения программ, а не инфологической модели базы данных.)

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

Это связано с абсолютно различающимися требованиями к базе данных прикладных программистов и администратора базы данных. Первые хотели бы иметь в одном месте (например, в одной таблице) все данные, необходимые им для реализации запроса из прикладной программы или с терминала. Вторые же заботятся о исключении возможных искажений хранимых данных при вводе в базу данных новой информации и обновлении или удалении существующей. Для этого они удаляют из базы данных дубликаты и нежелательные функциональные связи между атрибутами, разбивая базу данных на множество маленьких таблиц. Так как многолетний мировой опыт использования информационных систем, построенных на основе баз данных, показывает, что недостатки проекта невозможно устранить любыми ухищрениями в программах приложений, то опытные проектировщики не позволяют себе идти навстречу прикладным программистам (даже тогда, когда они сами являются таковыми).


Leave a Comment

Your email address will not be published. Required fields are marked with *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Pin It on Pinterest

Яндекс.Метрика