Модели данных (Виды и характеристики)

                   К основным понятиям иерархической структуры относятся:

1)уровень

2) элемент (узел), связь.

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

       К каждой записи базы данных существует только один (иерархический) путь от корневой записи. Например, как видно из рис.8, для записи С4 путь проходит через записи А и В3.

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

                                       Иерархическая модель данных.

        В сетевой структуре при  тех  же  основных  понятиях  (уровень,  узел,

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

          Сетевая  модель  СУБД  во  многом  подобна   иерархической:   если   в

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

                                      Иерархическая модель данных..

                  Понятие реляционный (англ. relation — отношение) связано с разработками известного  американского специалиста в   области   систем   баз   данных, сотрудника фирмы IBM д-ра Е. Кодда (Codd E.F., A  Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June  1970),  которым впервые был применен термин "реляционная модель данных". В течение долгого времени реляционный подход  рассматривался  как удобный формальный аппарат анализа баз данных,  не  имеющий практических перспектив, так как его реализация  требовала слишком больших машинных ресурсов. Только с появлением персональных ЭВМ реляционные и близкие к ним системы стали распространяться,  практически не  оставив   места   другим моделям.  Эти модели характеризуются простотой структуры данных,  удобным для пользователя   табличным   представлением   и   возможностью   использования формального аппарата  алгебры отношений и реляционного  исчисления   для обработки данных.  Реляционная модель  ориентирована на  организацию данных   в   виде двумерных таблиц. Каждая реляционная таблица представляет  собой двумерный

массив  и обладает следующими свойствами:

           - каждый элемент  таблицы - один  элемент данных; повторяющиеся   группы отсутствуют;

       - все столбцы в  таблице однородные, т.е. все элементы  в столбце имеют  одинаковый тип  (числовой, символьный  и т.д.) и длину;

       - каждый столбец  имеет уникальное  имя;

       - одинаковые строки  в таблице отсутствуют;

       - порядок  следования  строк  и   столбцов  может   быть  произвольным.

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

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

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

                                                        1.3 Язык SQL

                  Доступ к данным  осуществляется в  виде запросов  к базе данных, которые формулируются  на стандартном  языке запросов. Сегодня  для большинства  СУБД таким языком  является SQL. Появление  и развития этого  языка как средства  описания доступа  к базе данных  связано с созданием  теории реляционных  баз данных. Язык SQL имеет официальный  стандарт - ANSI/ISO. Большинство  разработчиков СУБД  придерживаются этого  стандарта, однако  часто расширяют  его для реализации  новых возможностей  обработки данных. SQL не является языком  программирования  в традиционном  представлении. На  нем пишутся не  программы, а запросы  к базе данных. Поэтому SQL - декларативный  язык. Завершая обсуждение  языка SQL, подчеркнем, что это - язык  запросов. На нем  нельзя написать  сколько-нибудь сложную  прикладную программу,  которая работает  с базой данных. Для этой цели  в современных  СУБД используется  язык четвертого  поколения (Forth Generation Language - 4GL), обладающий как основными возможностями процедурных языков третьего поколения (3GL), таких как Си, Паскаль, Ада, так и возможностью встроить в текст  программы операторы SQL, а также средствами управления интерфейсом пользователя (меню, формами, вводом пользователя и т.д.). Сегодня язык 4GL - это один из фактических стандартов средств разработки приложений, работающих с базами данных.

                            БЕЗОПАСНОСТЬ БАЗ ДАННЫХ

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

                                              Заключение.

  Пользователями БД являются четыре основные  категории  потребителей  ее информации и/или поставщиков информации для нее:

       - конечные пользователи,

       - программисты и  системные аналитики,

       - персонал поддержки  БД в актуальном  состоянии,

       - администратор БД.

       Хорошо  спроектированные   СУБД   используют   развитые   графические интерфейсы   и   поддерживают   системы   отчетов,   отвечающие    специфике пользователей указанных четырех категорий. Персонал поддержки БД и  конечные пользователи могут легко  осваивать  и  использовать  СУБД  для  обеспечения своих потребностей без какой-либо специальной подготовки Цель моделирования – обеспечение  наиболее  естественных  для  человека способов  сбора  и  представления  той  информации,  которую  предполагается хранить в создаваемой базе данных.  При проектировании программ выясняются запросы и  пожелания  клиента  и определяется возможный подход к решению  задачи.  Задача  анализируется.  На основе этого анализа реализуется конкретная модель в конкретной  программной среде. Результаты  каждого  этапа  проектирования  используются  в  качестве исходного материала следующего этапа.  Анализируется текущая организация предприятия, выделяются проблемы  для решения, определяются объекты отношения  между  ними,  составляется  «эскиз» текущей организации предприятия, разрабатывается модель с учетом  конкретных условий ее функционирования.  База  данных  ориентирована на  определенную  предметную   область   и организована на  основе  некоторого  подмножества  данных.