Учёт в экологическом законодательстве (База данных)

Российской Федерации  по согласованию с органами государственной  власти

субъектов  Российской  Федерации,  на  территориях  которых  находятся

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

иностранных   государств  облученных  тепловыделяющих  сборок  ядерных

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

окружающей  среды  в  районе  их  размещения  и  принципа радиационной

эквивалентности.

     4. Транспортирование  облученных  тепловыделяющих  сборок ядерных

реакторов осуществляется в соответствии  с  установленными  правилами, нормами и требованиями перевозок особо опасных грузов.

     5. В  бюджеты  субъектов   Российской  Федерации,  на  территориях которых   находятся   организации,   осуществляющие   деятельность  по переработке

6

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

Этапы проектирования БД.

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

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

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

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

7

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

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

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

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

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

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

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

 

Модели данных.

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

8

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

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

 

Инфологическая  модель. Основные понятия.

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

9

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

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

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

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

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

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

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

Таблица – упорядоченная структура, состоящая из конечного набора однотипных записей.

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

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

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

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

10

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

они могут участвовать  в других ассоциациях и обозначениях точно так же, как стержневые сущности; 

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

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

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

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

 

О построении инфологической модели.

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