Алматы экономика және статистика академиясы



жүктеу 5,01 Kb.
Pdf просмотр
бет21/30
Дата14.12.2017
өлшемі5,01 Kb.
#4331
1   ...   17   18   19   20   21   22   23   24   ...   30

57 
 
Кәзіргі уақыттағы деректер қорын басқару жүйесінің теориясы 
Деректер қоры концециясы 
Активная деятельность по отысканию приемлемых способов обобществления непрерывно 
растущего  объема  информации  привела  к  созданию  в  начале  60-х  годов  специальных 
программных  комплексов,  называемых  "Системы  управления  базами  данных"  (СУБД). 
Этому  предшествовал  первый  опыт  использования  файловых  систем  для  организации  баз 
данных. Файловые системы выявили различные проблемы обработки большого количества 
информации  и  заложили  основные  направления  развития  теории  баз  данных.  Вот  список 
лишь нескольких потребностей, которые не покрывались возможностями систем управления 
файлами: 
• 
поддержание логически согласованного набора файлов 
• 
обеспечение языка манипулирования данными 
• 
восстановление информации после разного рода сбоев 
• 
реально параллельная работа нескольких пользователей. 
Можно считать, что если прикладная информационная система опирается на некоторую 
систему  управления  данными,  обладающую  этими  свойствами,  то  эта  система  управления 
данными  является  системой  управления  базами  данных  (СУБД).  Основная  особенность 
СУБД – это наличие процедур для ввода и хранения не только самих данных, но и описаний 
их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся под 
управлением СУБД, стали называть банки данных, а затем "Базы данных" (БД). 
Приведем типовую схемы организации работы с СУБД. 
 
Рис.1 Связь программ и данных при использовании СУБД 
1. 
Архитектура СУБД 
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех, 
которые практически не имеют и (или) не хотят иметь представления о:  
• 
физическом размещении в памяти данных и их описаний;  
• 
механизмах поиска запрашиваемых данных;  
• 
проблемах,  возникающих  при  одновременном  запросе  одних  и  тех  же  данных 
многими пользователями (прикладными программами);  
• 
способах  обеспечения  защиты  данных  от  некорректных  обновлений  и  (или) 
несанкционированного доступа;  
• 
поддержании  баз  данных  в  актуальном  состоянии  и  множестве  других  функций 
СУБД.  


58 
 
При выполнении основных из этих функций СУБД должна использовать различные 
описания данных. Отметим, что проектирование этих описании обычно поручается человеку 
(группе лиц) – администратору базы данных (АБД). 
Рис.2   Уровни моделей данных 
Объединяя  частные  представления  о  содержимом  базы  данных,  полученные  в 
результате  опроса  пользователей,  и  свои  представления  о  данных,  которые  могут 
потребоваться  в  будущих  приложениях,  АБД  сначала  создает  обобщенное  неформальное 
описание  создаваемой  базы  данных.  Это  описание,  выполненное  с  использованием 
естественного  
языка,  математических  формул,  таблиц,  графиков  и  других  средств,  понятных  всем 
людям, работающих над проектированием базы данных, называют инфологической моделью 
данных (рис.2). 
Такая  человеко-ориентированная  модель  полностью  независима  от  физических 
параметров  среды  хранения  данных.  В  конце  концов  этой  средой  может  быть  память 
человека, а не ЭВМ. Поэтому инфологическая модель не должна изменяться до тех пор, пока 
какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения, 
чтобы эта модель продолжала отражать предметную область. 
Остальные модели, показанные на рис.2, являются компьютеро-ориентированными. С 
их помощью СУБД дает возможность программам и пользователям осуществлять доступ к 
хранимым  данным  лишь  по  их  именам,  не  заботясь  о  физическом  расположении  этих 
данных.  Нужные  данные  отыскиваются  СУБД  на  внешних  запоминающих  устройствах  по 
физической модели данных. 
Так  как  указанный  доступ  осуществляется  с  помощью  конкретной  СУБД,  то  модели 
должны быть описаны на языке описания данных этой СУБД. Такое описание, создаваемое 
АБД по инфологической модели данных, называют даталогической моделью данных. 
Трехуровневая  архитектура  (инфологический,  даталогический  и  физический  уровни) 
позволяет обеспечить независимость хранимых данных от использующих их программ. АБД 
может при необходимости переписать хранимые данные на другие носители информации и 
(или) реорганизовать их физическую структуру, изменив лишь физическую модель данных. 
АБД может подключить к системе любое число новых пользователей (новых приложений), 
дополнив,  если  надо,  даталогическую  модель.  Указанные  изменения  физической  и 
даталогической  моделей  не  будут  замечены  существующими  пользователями  системы 
(
окажутся  "прозрачными"  для  них),  так  же  как  не  будут  замечены  и  новые  пользователи. 
Следовательно,  независимость  данных  обеспечивает  возможность  развития  системы  баз 
данных без разрушения существующих приложений. 


59 
 
Инфологическая модель данных "Сущность-связь" 
Цель  инфологического  моделирования  –  обеспечение  наиболее  естественных  для 
человека способов сбора и представления той информации, которую предполагается хранить 
в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по 
аналогии с естественным языком (последний не может быть использован в чистом виде из-за 
сложности  компьютерной  обработки  текстов  и  неоднозначности  любого  естественного 
языка).  Основными  конструктивными  элементами  инфологических  моделей  являются 
сущности, связи между ними и их свойства (атрибуты). 
Сущность  –  любой  различимый  объект  (объект,  который  мы  можем  отличить  от 
другого),  информацию  о  котором  необходимо  хранить  в  базе  данных.  Сущностями  могут 
быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, 
как  тип  сущности  и  экземпляр  сущности.  Понятие  тип  сущности  относится  к  набору 
однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр 
сущности  относится к конкретной  вещи  в наборе.  Например,  типом  сущности  может  быть 
ГОРОД, а экземпляром – Москва. 
Атрибут  –  поименованная  характеристика  сущности.  Его  наименование  должно  быть 
уникальным  для  конкретного  типа  сущности,  но  может  быть  одинаковым  для  различного 
типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, 
АВТОМОБИЛЬ,  ДЫМ  и  т.д.).  Атрибуты  используются  для  определения  того,  какая 
информация должна быть собрана о сущности.  
Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут 
является таковым только в связи с типом сущности. В другом контексте атрибут может 
выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это 
только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности. 
Ключ  –  минимальный  набор  атрибутов,  по  значениям  которых  можно  однозначно 
найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора 
любого атрибута не позволяет идентифицировать сущность по оставшимся.  
Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных 
было только хранение отдельных, не связанных между собой данных, то ее структура могла 
бы быть очень простой. Однако одно из основных требований к организации базы данных – 
это  обеспечение  возможности  отыскания  одних  сущностей  по  значениям  других,  для  чего 
необходимо установить между ними определенные связи. А так как в реальных базах данных 
нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может 
быть  установлено  более  миллиона  связей.  Наличие  такого  множества  связей  и  определяет 
сложность инфологических моделей. 
Реляционная структура данных 
В  конце  60-х  годов  появились  работы,  в  которых  обсуждались  возможности 
применения  различных  табличных  даталогических  моделей  данных,  т.е.  возможности 
использования  привычных  и  естественных  способов  представления  данных.  Наиболее 
значительной  из  них  была  статья  сотрудника  фирмы  IBM  д-ра  Э.Кодда  (Codd  E.F.,  A 
Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, 
впервые был применен термин "реляционная модель данных".  
Будучи  математиком  по  образованию  Э.Кодд  предложил  использовать  для  обработки 
данных  аппарат  теории  множеств  (объединение,  пересечение,  разность,  декартово 
произведение).  Он  показал,  что  любое  представление  данных  сводится  к  совокупности 
двумерных таблиц особого вида, известного в математике как отношение – relation. 
Наименьшая  единица  данных  реляционной  модели  –  это  отдельное  атомарное 
(неразложимое)  для  данной  модели  значение  данных.  Так,  в  одной  предметной  области 
фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три 
различных значения. 


жүктеу 5,01 Kb.

Достарыңызбен бөлісу:
1   ...   17   18   19   20   21   22   23   24   ...   30




©g.engime.org 2024
әкімшілігінің қараңыз

    Басты бет
рсетілетін қызмет
халықаралық қаржы
Астана халықаралық
қызмет регламенті
бекіту туралы
туралы ережені
орталығы туралы
субсидиялау мемлекеттік
кеңес туралы
ніндегі кеңес
орталығын басқару
қаржы орталығын
қаржы орталығы
құрамын бекіту
неркәсіптік кешен
міндетті құпия
болуына ерікті
тексерілу мемлекеттік
медициналық тексерілу
құпия медициналық
ерікті анонимді
Бастауыш тәлім
қатысуға жолдамалар
қызметшілері арасындағы
академиялық демалыс
алушыларға академиялық
білім алушыларға
ұйымдарында білім
туралы хабарландыру
конкурс туралы
мемлекеттік қызметшілері
мемлекеттік әкімшілік
органдардың мемлекеттік
мемлекеттік органдардың
барлық мемлекеттік
арналған барлық
орналасуға арналған
лауазымына орналасуға
әкімшілік лауазымына
инфекцияның болуына
жәрдемдесудің белсенді
шараларына қатысуға
саласындағы дайындаушы
ленген қосылған
шегінде бюджетке
салығы шегінде
есептелген қосылған
ұйымдарға есептелген
дайындаушы ұйымдарға
кешен саласындағы
сомасын субсидиялау