БД для PVT данных и отчетов

Последнее сообщение
lemon 128 15
Ноя 08

Уважаемые коллеги,

Хотел бы начать дисскусию по-поводу баз данных для хранения и обработки PVT отчетов. Поделитесь опытом, как вы храните данные по свойствам флюидов, систематизируете ли их и т.д. Используйте распространенные базы данных (типа access) или просто храните оригинальные отчеты в эл.папках на компьютере. Чтобы быть более понятным, приведу пример. У нас все отчеты (в формате doc), присылаемые из лабораторий (ТЦЛ, геодата и др.), хранятся просто в эл.папках соотсветствующих скважин. Если меня просили найти "среднее значение" конденсатосодержания по пласту, то мне приходилось "лопатить" папки скважин, работающих из данного пласта, открывать отчеты, сводить все данные в таблицу и только затем рассчитывать среднее значение. В один момент мне это надоело, я составил обширную таблицу в экселе, куда поместил все данные по свойствам из всех отчетов, систематизировал их по скважинам, пластам и т.д. Однако жизнь показала, что это тоже не выход...Недавно натолкнулся на один специализированный софт - "база данных для хранения PVT данных" (демо версия лежит на http://pvtreport.com/). В целом, софт неплохой, за исключением высокой цены (как, впрочем, и у всех софтов от Шлюмов). Поэтому я серьезно думаю, чтобы попробовать создать собственную базу данных, специально для PVT. Если у вас есть какие-либо мысли по этому поводу, с радостью приму их во внимание...

visual73 1945 16
Ноя 08 #1

lemon пишет:

...

Ну что ж, давай подискутируем wink.gif
Занимаюсь флюидами более 11 лет. Как экспериментальной частью так и моделированием. Занимался и конкретными своими отчетами и выполняли крупные работы по анализу флюидов по месторождению.
Все данные (и свои и других компаний) храню структурированно по каталогам. Формат - excel. Один отчет - один файл. Если работа крупная то несколько файлов. Вся инфа там не в виде базы данных а в виде таблиц.
Это я считаю самый удобный способ хранения данных.
Почему так а не в базе данных?
Да потому что хранение PVT данных в базе бессмысленно. Параметры получаемые в ходе PVT исследований, к сожалению, не тоже самое что интернет-магазин, товары которого можно рассортировать а потом вывести общую среднюю статистику. Нельзя и бессмысленно собрать все данные по залежи и осреднить их, потому что получится белиберда и компот. Например многие месторождения разрабатываемые 20-40 лет имеют 90% брака в PVT исследованиях. А если осреднить параметры в однофазной области и через некоторое время эксплуатации месторождения параметры уже двухфазной системы? А как осреднить параметры данные на разные глубины - а ведь все глубинные пробы имеют разную глубину отбора?
Короче если перечислять то можно книжку написать "Почему нельзя..?".
Для дальнейшего анализа месторождения данные PVT в формате "базы данных" хранить неудобно, нецелесообразно, и не нужно.
Программа же шлюмов нужна, как мне кажется, просто для хранения данных оператора установки PVT. Провел он какие-то опыты, занес в журнал (в данном случае программа). Потребовалось начальнику "поднять" какую-то пробу сделанную в 1999 г. - пожалуйста.
Но для такого хранения (не анализа) больше подходят не жестко настроенные программы, типа этой, а более гибкие, в которых можно быстро что-то просчитать, а потребуется и выполнить полномасштабный анализ материалов. И в этом незаменим - Excel.
Вот так.
P.S. Ну а если Вы считаете что я не прав, то попробуйте создать базу в Access. Я конечно не спец по БД, но немного работал в Access, и он мне показался очень гибким и удобным, хотя впрочем это наверно относится ко всем БД wink.gif
P.S.S. Давно ищу поглядеть эту и другие софтинки шлюмов (напр. PVT Pro), интересно поглядеть. А как ее взять демо-версию?

Dorzhi 970 17
Ноя 08 #2

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

serg1c 154 15
Ноя 08 #3

Мне кажется, что Excel не выход - это конечно очень удобный инструмент для многих задач, но не для создания/ведения баз данных, особенно если пользоваться будет более одного человека. Я бы порекомендовал автору поближе познакомиться с Access - он имеет очень много возможностей и практически все они доступны через визуальный редактор. На первом этапе все данные можно будет загрузить в базу, а для ввода новых данных создать форму, где можно задать условия не позволяющие вводит некондиционные данные, расчетные поля. Для обработки данных существует очень удобная система запросов, в которой при расчете можно будет учесть условия перечисленные visual73. Как исходные данные, так и результаты расчетов можно представить в виде отчетов, что позволит отказаться от вордовских документов.
У нас есть несколько решений в Access, правда не связанные с флюидами, которые работают уже около 10 лет и даже внедряемый профессиональный софт пока не заменил их, прежде всего потому что они были сделаны нами под нашу специфику и прекрасно выполняют свою задачу.

lemon 128 15
Ноя 08 #4

Спасибо за содержательный ответ.

Все это понятно: Excel вещь хорошая и незаменимая - не спорю. Но здесь, на мой взгляд, проблема кроется в другом. Из твоей записи следует, что ты хранишь данные в формате Excel для СЕБЯ, в удобном для СЕБЯ виде, в таблицах, сделанных ТОБОЙ (у меня, впрочем, такая же ситуация). Представим ситуацию: кому-нибудь, вдруг, потребуется узнать, например, потенциальное содержание конденсата по пласту или скважинам, или более сложные вещи: например, кто-то захочет проверить, какой GOR использовали при рекомбинации пробы, а какой - при промысловых исследованиях на сепараторе. Предполагаю, что этот человек пойдет к тебе (или пришлет запрос) за информацией. А если ты в отпуске, заболел или уволился ("нет человека - нет PVT данных")?. Даже если ты ему отправишь (или оставишь на сервере) свой файл в Экселе - сомневаюсь, что он сразу что-то там поймет и начнет тебя донимать вопросами. А если ты работаешь в крупной компании, где несколько тысяч работников. Тебя просто зае...ут разными запросами...Поэтому из своего опыта я решил, что база данных нужна. Чтобы любой работник без твоего участия мог посмотреть данные.

lemon 128 15
Ноя 08 #5

serg1c пишет:

Мне кажется, что Excel не выход - это конечно очень удобный инструмент для многих задач, но не для создания/ведения баз данных, особенно если пользоваться будет более одного человека. Я бы порекомендовал автору поближе познакомиться с Access - он имеет очень много возможностей и практически все они доступны через визуальный редактор. На первом этапе все данные можно будет загрузить в базу, а для ввода новых данных создать форму, где можно задать условия не позволяющие вводит некондиционные данные, расчетные поля. Для обработки данных существует очень удобная система запросов, в которой при расчете можно будет учесть условия перечисленные visual73. Как исходные данные, так и результаты расчетов можно представить в виде отчетов, что позволит отказаться от вордовских документов.
У нас есть несколько решений в Access, правда не связанные с флюидами, которые работают уже около 10 лет и даже внедряемый профессиональный софт пока не заменил их, прежде всего потому что они были сделаны нами под нашу специфику и прекрасно выполняют свою задачу.


Опыт интересный, однако помимо самих данных, иногда требуется вывести график или сравнить несколько проб по, например, давлению насыщения (в виде гистрограммы). Иногда требуется выгрузить состав флюида в формате, читаемом PVTi или PVTsim. Также желательно делать автоматические расчеты по введенным данным (например, расчет КИК и потенциального содержания). Или внедрить некоторые процедуры проверки качества проб (хотя бы правильность рекомбинации, или сравнения давления насыщения с пластовым), или применить функции статистического анализа (если не нравится расчет "средних" параметров) - о чем правильно говорил Vasual73. Насколько это возможно в Access?

Гоша 1201 17
Ноя 08 #6

lemon пишет:

Насколько это возможно в Access?


Возможно:
вызываем в VBA макросах статистические и иные функции Excel.
или отправляем выборку по SQL-запросу из базы (где "хранится первичка") в тот же Excel и уже считаем там.

serg1c 154 15
Ноя 08 #7

Гоша пишет:

Возможно:
вызываем в VBA макросах статистические и иные функции Excel.
или отправляем выборку по SQL-запросу из базы (где "хранится первичка") в тот же Excel и уже считаем там.

Мы тут человека за Access агитируем, а вы его опять в ексель направляете blush.gif Так как Access это часть пакета MS Office, то там доступны все функции (математические, статистические), что есть в Excel, и я думаю можно будет обойтись и без написания макросов, а все сделать в конструкторе. Единственное в чем для меня Access хуже Excel - это работа с записями - вы не сможете сцепить данные из разных строк в одну используя стандартные инструменты и т.д.
lemon - почитайте справку, посмотрите примеры - с аксессом идут БД для примера - самое сложное это правильно спроектировать БД.

Гоша 1201 17
Ноя 08 #8

Пропаганды Excel нет,
напротив все недостающие стат функции или PVT-корреляции реализуем макросами в том же Access.

serg1c пишет:

самое сложное это правильно спроектировать БД.


Это верно, в институте даже этому целый год учили... реляционные БД, нормальные формы...

Гоша 1201 17
Ноя 08 #9

Да, еще опыт работы на предыдущем месте показал нежизнеспособность реализации автономной системы (на уровне корпоративной БД) работы с PVT данными (базы в Interbase или Oracle с веб-интерфейсом). Что говорит только лишь в пользу прописной истины выбора оружия подходящего калибра для соответствующих мишеней.

lemon 128 15
Ноя 08 #10

serg1c пишет:

Мы тут человека за Access агитируем, а вы его опять в ексель направляете blush.gif Так как Access это часть пакета MS Office, то там доступны все функции (математические, статистические), что есть в Excel, и я думаю можно будет обойтись и без написания макросов, а все сделать в конструкторе. Единственное в чем для меня Access хуже Excel - это работа с записями - вы не сможете сцепить данные из разных строк в одну используя стандартные инструменты и т.д.


Насколько я понял Access - не готовое решение. Надо весь отдел IT задействовать, чтобы они "доводили до ума" Access. Для них необходимо написать техническое задание, проект и т.д. Неизвестно, сколько на это уйдет время... Тем более, я всегда считал, что "IT-guys" из другой планеты и говорят на другом языке. Я им не могу объяснить, что я хочу от них получить (начинают мне про всякие SQL и GUI мозги парить), они не могут представить, что хочу я.

serg1c 154 15
Ноя 08 #11

Access не готовое решение, а инструмент для его создания. И довести его до ума можете только вы, айтишникам там работы раз плюнуть - но сформировать задание должны вы, а для этого нужно поближе познакомиться с Access'oм да и вообще с БД. Я сомневаюсь, что существует готовое решение для вас - даже если, что то понравилось с первого взгляда не факт, что потом там не окажется нужной функции или места, где хранить нужные вам данные, а изменения эти ради вас делать никто не будет.
Если pvtreport для вашей компании дорогое решение, то может есть смысл изучить демо-версию, а на ее основе создать свое решение? Но в любом случае - быстрое решение не сможет решить всех задач и со временем "умрет" и вы сделаете, что либо новое или вернетесь заново перебирать файлы, создание хорошего инструмента требует больших затрат - прежде всего временных и особенно в такой области как свойства флюидов. Поэтому, если сейчас нет времени и желания разбираться, наверное лучше использовать Excel - в этом случае вы хотя бы приведете данные в вид подходящий для загрузки в БД с минимальными усилиями.

Dorzhi 970 17
Ноя 08 #12

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

serg1c 154 15
Ноя 08 #13

Dorzhi пишет:

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

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

Dorzhi 970 17
Ноя 08 #14

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

lemon 128 15
Ноя 08 #15

Спасибо всем за участие в дискуссии. Для себя я сделал определенные выводы. Обещаю Вам сообщать результаты работы по созданию нашей корпоративной базы данных. Вроде, начальство хочет ставить шлюмовский Finder. Посмотрим, что выйдет - самому интересно...

visual73 1945 16
Ноя 08 #16

lemon пишет:

что ты хранишь данные в формате Excel для СЕБЯ, в удобном для СЕБЯ виде, в таблицах, сделанных ТОБОЙ

Ага точно. Сам делаю, сам храню, сам анализирую smile.gif
А дать как ты говоришь доступ всем и вся, чтобы в твой отпуск тебя не беспокоили wink.gif все равно не получится, даже и с базой. Возьмут они какую-нибудь цифру (а уж какую взять может быть с десяток вариантов), а крайним все равно ты будешь laugh.gif

serg1c 154 15
Ноя 08 #17

visual73 пишет:

У Excel самое главное преимущество перед БД (в плане подхода к PVT), это то что Excel - это инструмент анализа, в котором всегда можешь посчитать вручную и провести расчеты - свободные расчеты, в отличии от Access.

А можно пример расчетов, какие можно свободно сделать в экселе и нельзя в аксессе, так для общего развития happy.gif

volvlad 2196 17
Ноя 08 #18

Присоединюсь к дискуссии, немного оффтоп но к теме очень близко.

Расскажу об опыте создания и внедрения БД в нашей компании.
Цель этой базы - создание системы для прогнозирования добычи, объединенной в единое целое с системой создаваемой в инвестиционном департаменте для управления проектами, бюджетом и пр. Понятно, что любые изменения в бюджете, в сроках ввода объектов в эксплуатацию, изменение ковра бурения влияют на добычу и наоборот. К тому же нужно рассчитать и сравнить несколько сценариев, также сделать расчеты под разные варианты запасов (P10, P50, P90).
Сначала все необходимое было сделано в Экселе, но после того как данных стало очень много, разрослось кол-во вариантов. Исходные данные и результаты расчетов хранившиеся в Excele стали ворочаться крайне медленно. решили перевести все в Access. В базу были занесены все данные необходимые для выполнения расчетов добычи. Базу по инвестициям сделали отдельно, придумав концепцию для эффективного обмена необходимыми данными между этими двумя базами. В базе по добыче храниться все необходимое для расчета добычи - данные по месторождениям, пластам, по скважинам, PVT, информация по объектам наземной инфраструктуры. В общем все, что необходимо было для эффективного и быстрого управления интегрированной моделью добычи построенную в GAP/MBAL.

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

Почему в качестве СУБД был выбран Access:
- простота и наглядность - все визуально, для построения простой БД в принципе не нужно знать SQL. Хотя лучше все же знать, иначе придется потом тяжко с написанием запросов.
- доступность - установлен везде где есть MSOffice, не требует установки доп. софта.
- интеграция с Excel - в Excel импортируются данные по кторым нужно строить графики, диаграммы, сводные таблицы и пр. Источники данных (таблицы, SQL запросы) формируются либо в самом Access, либо в Excel в формах или макросах. Именно из-за этой интеграция, было решено отказаться от mySQL, который скорее всего по скорости обработки данных обгоняет Access.

serg1c пишет:

А можно пример расчетов, какие можно свободно сделать в экселе и нельзя в аксессе, так для общего развития happy.gif

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

Но Access гораздо быстрее ворочает таблицы с большими объемами данных... В Экселе это значительно медленнее, есть способы оптимизации, например, отключение обновления экрана, временное выключение автоматического расчета ячеек и т.д. Но при достаточно больших объемах эти меры становятся неэффективными.

Eugene 545 16
Ноя 08 #19

Хочу также прокомментировать данную проблему.

На мой взгляд и опыт, как и вывод из коммента visual73, проблема в том, что ПВТ значимы, только вместе с отчетами.

Я сделал БД ПВТ по месторождению, на котором я сейчас работаю, в Экселе. Причем постарался учесть то, что БД будут пользоваться без меня, т.е. есть описания, комменты и т.п. Всего 470 КБ, но учитывая что там только исследования по 22 скв...

Плюсы
- быстрый доступ к результатам исследований за все время

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

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

Мне не нравятся идеи и продукты, которые выкидывают детали и выдают какие-то коцаные цифры, типа Bo=1.31.
Для тех кто понимает - это бред. Какое давление, температура, вид разгазирования?

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

serg1c 154 15
Ноя 08 #20

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

visual73 1945 16
Ноя 10 #21

я выступал против базы, и вот судьба поставила перед фактом... laugh.gif
Кто бы мог подумать...я её сделал. Сделал в том в чём умею, в аксесе (если смущают ограничения, то всегда можно переложить в любую SQL).

Ну что можно сказать про такое решение?
Оно жизнеспособно! Но лишь в том случае, если
1. Из базы всегда можно выудить всю информацию в форме исходного отчёта PVT, представленного в любой форме, в любом объёме исследований.
2. можешь поручиться на 99% за людей которые будут наполнять эту базу.

Второй пункт очень сложен т.к. требует больших затрат по времени (имеется ввиду не 10-50 отчётов, а тысячи).
Возвращаюсь к словам сказанным два года назад - базу нужно делать самому, своими руками. Убил бы базовиков только за то что они "лучше меня знают как создать базу"!

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

Буду рад услышать какие-то новости и от других участников этой темы.

kunkaci 11 9
Дек 16 #22

Добрый день, коллеги, я работаю в петрофизической лаборатории - проводим исследования керна. Данные на промежуточном участке от лаборатроной установки до составления отчета хранятся на одном компьютере. Чтоб не путатся начал структурировать все- раскладывать по папочкам: тип исследования, месторождения, скв, пласты итд таких папок с файлами excel собралсь уже очень много, появилась мысль что логическим продолжением было бы создание какой то БД для удобства пользования "для себя" внутри лаборатории. подскажите кто уже проходил такой этап (visual73) как в вашем случае работает ваша БД и что из себя представляет? вообще с access я практически не знаком, с горем пополам осваиваю макросы для замены однотипных процедур обработки исходных файлов, но результат мне уже понравился) время обработки по образцам одной подборки сократилось кратно. Я правильно представляю себе что БД- это по сути множество связаных между собой таблиц с возможностью их анализа/записи/перезаписи/редактирования . если это так то наверно можно настроить все так, что занеся в бд все необходимые данные затем можно будет провести автоматический расчет и составение практически готового отчета

YanP 197 15
Дек 16 #23

Очень давно занимался подобной базой по керну и флюидам. Только это было на уровне конечных исследований.
Технически подобная база - это набор таблиц, объединенных единой индексной системой. Всё это крутится под единой оболочкой (СУБД). Тогда это был DataBase6 (*.db) под FoxPro. Плюс специально написанная оболочка СУБД. Кроме этого я пользовался связкой Excel-Access.
Знаю, что в те годы керновая лаборатория СургутНИПИнефть занималась созданием такой базы. Был доклад на Пути реализации НГ потенциала ХМАО. Года 2003-2005, точнее не помню.

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

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

MironovEP 2019 15
Дек 16 #24

Visual73 боюсь Вам уже не ответит. он принципиально ретировался с данного форума несколько лет назад

rbildano 240 12
Дек 16 #25

Посмотрите ResView, возможно то что ищите.

Go to top